AD-A285  507 


Copy  oO  ofTSeopiis 


IDAPAPER  P-2664 


INFORMATION  INFRASTRUCTURES  FOR 
INTEGRATED  ENTERPRISES 


Robert  L  Winner,  Ibsk  Leader 


May  1993 


DTIC 

ELECTE  1% 
OCT  1119941  B 

o  Ei 


j 


Prepared for 

Advanced  Research  Injects  Agency 


INSTITUTE  FOR  DEFENSE  ANALYSES 

1801  N.  Beauregard  Street,  Alexandria,  Virginia  22311-1772 


0  i  0  4: 


IDALO|IIO.IfQ014MO541 


ktIKMl  DOCl  Vlt STATIOS  PAGE 


Fuan  Afifaovcti 
Ko 


«mew>aku>.  tMr^su4|;  ciiiuiiti;  dAi;i  MKlrce^, 

'I*  ii*^»iii  ».-■*  ^  V  .fc  4V  Jho  lUM^api-  ariU-^c  ui  uhrf  A»pei't  oj  ihLs 

'Mi0i„ itm  /I  .4^45^^—  ■*»  "**  WN**'*^*--**** •'■***’**»«  •  ^■Mnai****  .«uQ^A^  jta  •4i.«n^i«^c4i0«kK«b-*u<sRcfM.vi».  (21^  JefferscKi 

>yi|il>’ij  'ir  <!««(  '  t*  Afo*  ■«  4— a^^***'*  r'.«-.\|4  { M '  d).V>3 


-4iili». 


•«nK 

'*>■: 


‘  liH  a.M.1  UaU' 1 1»\ tKtl) 

HlMt^ 


i  iTT^  a£PC>  ^S^WTTTt-^ 


4*^ 


R'fciUVi.  M  I4l*t4(.^ 

MDA  «V  C  OtlO^ 


ARPa  .Kxsigaaean  A-I6() 


urTWtt^ 

4(4IBM .  < 


t  mmtk  t  t^t  t  .« 

MW  t  «mw  ^^Hfn  ».i  ntmt  i> 


'SKpA  JOUTK.'J  •X'l  vM^iteiM  i?r\ 


Mill  4 


lA  '-in  i  ‘  '  ‘  • 


’♦  iSi^MMrt**^  lA^KOArius  k0^T 
if.iwAltA 


lUA  *>pM  F-.?iei«a 


:  ^1  '#  ^wlw  Aivtfc 

lA  *  •  * '  >* 


Fr^~  .A  vf*  siisl *1t  ..\nt~ "I  iTWW  Si jrkTi 


MumHUIl 


"iW-iAtflN'^W  JS.lMr 


1*  ’iiT—'  TH  III  umi ; 


«WWWw*iP**4 


A#  W  * 


«»  M»  MIH  TW  c 


tvfmvedwi' 


ssa 


iw,  «k|ir» -mWF 


» fAMnwrarA  m  Mtrnurr 


IDA  PAPER  P-2664 


INFORMATION  INFRASTRUCTURES  FOR 
INTEGRATED  ENTERPRISES 


Robert  I.  Winner,  Task  Leader 

Harold  E.  Bertrand 
Mark  E.  Brown 
Earl  F.  Ecklund,  Jr. 
Marvin  H.  Hanunond,  Jr. 
Deborah  Heystek 
Fred  Tonge 
Richard  D.  Tracey 
Jack  F.  White 


May  1993 


AppmM  (or  oMic  roMito,  nllmnoO  tflftribotton:  tafiot  16. 1994. 


INSTITUTE  FOR  DEFENSE  ANALYSES 

Contract  MDA  903  89  C  0003 
ARPA  Assignment  A- 160 


) 


PREFACE 


This  document  was  prepared  by  the  Institute  for  Defense  Analyses  tIDA  t  midtet  ntc 
Advanced  Research  Projects  Agency  (ARPA)  Assignment  A- 160.  DARPA 
and  Manufacturing,  and  fulfills  an  objective  of  the  task,  “to  assist  DARPA  ui  «t> 

approach  to  engineering  and  manufacturing  process  technology."  The  Mori  was 
sponsored  by  the  Computer-Aided  Acquisition  and  Logistics  St^ipon  Dif«K.iniair  <«r  «nr 
Office  of  the  Assistant  Secretary  of  Defense  (Production  St  Logistics)  m 
the  U.S.  Air  Force  Manufacturing  Technology  Directoraie  and  the  Softinarr  md  laattMimM 
Systems  Technology  Office  of  ARPA.  under  Task  Order  T-B5-M9.  PrtwiMr  Unuwiaani 
Information  Infirastructures. 

A  peer  review  of  this  paper,  chaired  by  Dr.  Richard  J.  IvaaciKh.  mm  frthmwna  hf 
following  IDA  research  staff  members:  Mr.  Herbert  R.  Brown.  Oi  Kvlow  Hrwat.  ^ 
Michael  W.  Marean,  Dr.  J.  Richard  Nelson.  Dr.  Karen  J.  RidMcr.  and  Di  Ralnn  U  RcMr 

The  authors  gratefully  acknowledge  the  technical  cownbtnions  otadr  dw 

ing  people:  Mr.  Alan  L.  Baum,  Mr.  Shantanu  Dhv.  Ms.  JacqiKltne  A  Gdns  k*  Maiiwii 
McFarland,  Mr.  K.H.  Maralidhar,  Mr.  Robert  S.  Matthews.  Mr  Tory  Maydwld  t*  D 
Paraunak,  Mr.  Thomas  A.  Phelps,  Dr.  Larry  H.  Reekcr.  Mr.  John  Sa«n.  mts  Mi  Mnitunti 
T.  Wood.  We  especially  appreciate  the  efforts  of  the  fbUownif  people  «ah»  pTiignii  Ww 
document  for  publication:  IDA  editors  Ms.  Kaiydean  Price  Md  Ms  SfHm  dii 

m  editor  Mr.  Van  D.  Parunak,  and  IDA  support  staff  member  Ms  WMMir  mma  f  Ti 
support  staff  member  Ms.  Darlene  McMordie. 
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TlMf  Depmvnnem  of  Defense  (DoD).  as  a  large,  complex  set  of  enterprises,  as  a  pur- 
of  compleji  sysieim,  and  as  a  partner  with  industry  in  the  development  of  those  sys- 
wme,  uandft  id  gaw  a  greai  deal  from  the  efficiencies  and  effectiveness  of  more  integrated  | 

4i.uvUMe».  Thcfc  is  an  opponunity  for  both  industry  and  government  to  explore  the 
apfiMNtclie*  and  issues  within  enterprise  integration  and  industrial  information  inffastruc- 
oiws  and  ID  atxelmafe  sDluuons. 


The  DoO  mktd  the  Instituie  for  Defense  Analyses  (IDA)  to  assess  industry  efforts 
aed  uMiif  n/ormaiion  infrastructures  to  help  integrate  activities  in  enterprises, 
'fffekiik^ady,  IDA  was  lo  determine  why  companies  are  investing  in  integration,  what 
hrartwj  conpanies  are  nuking,  what  the  key  issues  are  and  their  implications  for 
Di»D,  whin  proffcM  rckvant  cooperative  and  standardization  efforts  are  making,  and  what 
a  at  hw  haiuK  m  the  yw  2001  might  be.  The  intent  of  this  report  is  to  act  as  a  starting 
pMM  to*  in  open  dfcicit5UMOA  of  rationales,  approaches,  and  issues.  A  set  of  recommenda- 
(MKM  lD«  DoD  acoott  M  proposed  for  discussion. 
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The  hMic  Idea  of  imegration  is  to  increase  the  interaction  among  the  various  actors 
*  people  and  machmea)  m  previously  squrate  processes.  Concurrent  engineering  is  an 
eaample  of  procesa  imefraiiotL  Previously  separate  product  and  process  engineering  activ-  ^ 

»«e<*,  vlteeacierued  by  sequential  execution  and  batched,  “over-the-wall”  information 
iowa,  m  bewf  mcreasingly  integrited  into  processes  with  intensely  interactive  informa- 
Uoa  Ihrwa.  The  waaioag  imegrated  product  and  process  engineering  yields  significant  qual- 
ay,  veal,  aad  schedule  improvements.  An  effective  and  efficient  information  flow  is  i 

recopaiaad  ae  aa  enpomai  factor  in  establishing  integrated  activities.  Applying  integration 
lo  pasKeMMRi  diroughoal  the  value-chain,  across  functional  organizations  and  company 
IUiuadhriea>  ytehh  csNcrprise  integration.  The  set  of  capabilities  aggregated  to  support  the 
mparirt  uargraied  iafarmation  flow  is  the  industrial  information  infirastructure.  All  22 
cumpuaHii  snahed  for  this  report  are  anempting  to  create  or  use  information  infrastructures 
ID  lupport  tnugratioo  in  various  ways  and  to  various  degrees. 


CoropoiMs  reported  significant  improvements  realized  from  integration  of  activi- 
supported  by  information  systems.  Most  of  these  improvements  fall  into  categories  of 
coui  wwfsiction  or  avoidance,  cycle  time  reductions,  quality  improvements,  and  capacity 
inciuaaua  (see  Table  S- 1 ).  The  division  of  results  into  these  categories  is  somewhat  artificial 


VI 


Enterprise 
Integration  and 
Streamlining 
(Overall) 


Engineering  and 
Design 


since  most  improvements  can  be  thought  of  as  belonging  in  more  than  one  caicgor>'.  For 
example,  most  of  the  reported  quality  improvements  resulted  in  significant  cost  savings  or 
avoidance. 

Table  S-1.  Improvements  by  Business  Function 


QUALITY 


COST 


SATURN:  20%  across  the 
board  savings  (est). 

DEC:  30%  ROI  from  CIM. 

CROSS  AND  TRECKER: 
30%  return  on  new  inte¬ 
grated  system. 

PRATT  AND  WHITNEY, 
reduction  in  bid  savings 
$10M  in  one  area  and 
$20M  in  another. 

MARTIN  MARIETTA, 
reduction  of  work  force  by 
over  40%  while  business 
increased  by  3%. 


DEC:  90%  reduction  in 
design  data  admin  staff; 
83%  reduction  in  design 
data  coordinators. 


CYCLE 


NEXT:  product  shipped  in 
11  monihs,  5  months 
before  competitors. 

MOTOROLA:  oeUuiar  prod¬ 
uct  cyde  reduced  50% 

NATIONAL  SEMICON 
DUCTOR:  time  to  market 
reduced  from  2  years  to  9 
iTtonths  in  some  cases 


Test  and  Mock- 
ups 


Manufacturing 
Engineering, 
process 
planning,  tool 
design 

Operations 

including 

materials 

management 


MARTIN  MARIETTA: 
reduction  from  2, 100  hours 
to  900  hours  engmeering 
time  for  mock-up. 


Tl:  90%  reduction  in  order 
entry  labor  for  mask. 

MARTIN  MARIETTA: 
reduction  of  10  tool  desigtv 
ers  to4 


FORD;  10-15%  reduction 
in  sheet  metal  opeftions. 

SATURN:  work  in  process 
raduood  born  5  dqrs  to  SO 
minutos. 

DEC:  reduced  assembly 
line  work  force  Irom  290  to 
TOworkws. 


MOTOROLA:  50%  reduc¬ 
tion  in  design  cycle  tor 
products  using  ASICs 

MARTIN  MARIETTA 
reduced  board  dsvelop- 
mont  iloratiotM  Irom  2  S  to 
1.5 


FORO:oniradieMh 
reduction  ol  pNysioal 
els  by  90% 


QM:  torrease  of  taction  ol 
Inventory  in  use  to  99% 


•eeoibto 

MOTORCXA  ft-wetokto  « 

neiFCS 

supply  and  aa 

cycle 

FORD  reduol 

by  lti%«»e 

'  u,4n^  <iMil»,  i»iw»w>  >«»  Oiwwt  4im  »»*«ii>— f  •»  mpk  m  IfH  iilwilwifli'  a(  mii- 

i|«4«»  «f  IMIiv*  K*  nm)  w«»  t»fiK)il  Ajmacw  pncocT  in  the 


•  »iNlwn»«i#  iNMinMMli*  «N|Mi««MaMii  i»  fnnfcn*^  Iw^  pnxeMet  such  as  design 

tUnVitaiMNi  •  >  '•MiAii «  «  ««iMMkHif  a  new  ckcvonics  manufacturing 

ttiiu  itMlia  <i#  (NugnNiMfer  MPritettnax  pMMiwMMf  IM  release  (6  months  to  I 
aiMisx  amrs  tMliKSans 

•  QMliiy  nmsaM  swim  «k»  as  tales  (Sttned  at  5%.  went  to  50%. 

mm  ai  a^x  asw  INa  mxk  efs^  and  55%  dBcieaied  drawing  changes. 

•  adiudiaiailng  kitm  fsedasiriity  iw^uiemeim  as  tegh  as  a  factor  of  15  to  20 
aampuNd  wMS  aampadpf  ceanfM^  ft*  **^  manufacturing  touch-labor 


hour^),  increases  in  fraction  of  inventory  actually  in  use  (was  5%,  now  95%), 
and  similar  decreases  in  work  in  progress. 

In  general,  integrated  activities  in  the  design  and  production  of  complex  products, 
when  supported  by  a  relatively  integrated  information  infrastructure,  have  proved  to  result 
in  higher  quality  processes,  designs,  and  products. 

Significant  process  improvements  are  reported  in  the  ability  to  manage  change, 
making  the  enterprise  more  agile.  Changes  range  from  large  and  broad  (introduction  of  a 
new  product  or  abrupt  changes  in  demand  for  an  existing  product)  to  focused  (introduction 
of  a  design  change  to  a  product  already  in  full-scale  production).  Some  people  regard  this 
agility  as  the  most  important  underlying  reason  for  investing  in  information  infrastructures 
for  enterprise  integration. 

Why  Information-Based  Intonation  Works 

The  fundamental  reason  that  information-based  integration  works  is  fairly  simple. 
Previously,  computers  have  been  used  to  centralize  information,  logically  if  not  physically, 
about  such  organizational  data  as  payrolls  and  bank  accounts.  Errors  are  prevented  and  pro¬ 
cesses  accelerated  to  a  great  extent  because  logically  centralized  information  can  be  coor¬ 
dinated.  Enterprise  integration  extends  the  application  of  this  concept  to  the  product  life 
cycle.  Consider  all  the  information  about  a  product — ^its  design,  the  engineering  analyses, 
the  design  intent,  the  parts  codes,  costs,  maintenance  data — and  the  processes  that  surround 
the  product — ^assembly  modeling,  process  planning,  manufacturing  process  description, 
simulation,  purchase  scheduling,  logistics  planning.  Now  consider  the  discipline  required 
to  coordinate  all  that  information  among  a  large  number  of  people,  especially  where  the 
information  is  distributed  and  on  paper.  Integrating  the  information  on  computer  systems 
causes  a  new  level  of  discipline  in  coordinating  tiie  myriad  of  information  related  to  the 
products  of  the  enterprise. 

Making  the  information  easier  to  coordinate,  in  turn,  relieves  the  enterprise  from 
using  a  divide-and-conquer  solution  for  control  of  its  activities.  That  means  the  people  who 
execute  the  activities  can  work  together  and  coordinate  their  thinking  rather  than  being  arti¬ 
ficially  separated  for  the  purpose  of  controlling  the  information  they  produce. 


^  “Sales  per  manufacturing  touch-labor  hour”  is  a  measure  of  manufacturing  productivity.  It  is  calculated  as 
the  total  sales  volume  in  monetary  terms  (e.g.,  dollars)  divided  by  the  total  number  of  person-hours 
required  to  produce  the  products  being  sold.  Person-hours  count  only  those  people  who  directly  interact 
during  manufacturing  with  the  product,  its  components,  ai  with  the  machines  that  process  the  product 


IX 


All  this  is  borne  out  in  the  cases  described  in  the  report  and  its  appendices.  For 
example,  if  a  centralized,  three-dimensional  computer  model  of  a  product  exists,  it  is  rela¬ 
tively  easy  to  plan  part  assemblies  in  the  same  model.  It  is  hard  to  miss  that  two  parts  will 
not  fit  or  that  they  will  interfere.  The  discipline  required  for  this  kind  of  coordination  of 
effort  is  fundamentally  different — quicker,  less  costly,  and  less  error-prone — from  mylar 
drawings  and  paper  assembly  plans  having  to  be  mated  to  create  a  product. 

The  activities  of  product  design,  manufacturing,  and  assembly  can  be  coordinated 
to  a  much  greater  degree  because  of  the  ability  to  integrate  information  flow.  Large  num¬ 
bers  of  people  can  work  together  to  reach  a  common  goal.  These  people  can  be  in  separate 
but  cooperating  companies  to  the  extent  that  cross-company,  integrated  information  infra¬ 
structures  have  been  put  in  place. 

DoD  Interests 

DoD  has  three  roles  connected  with  enterprise  integration  and  information  infra¬ 
structures; 

•  Asa  customer  for  enterprise  integration  and  infrastructures  for  its  own  internal 
systems  and  processes,  for  example,  acquisition,  logistics,  financial  planning, 
and  management. 

•  Asa  partner  with  industry  in  weapon  development  and  procurement  and  there¬ 
by  a  member  of  an  inter-organizational  team  with  a  need  for  streamlined  pro¬ 
cesses. 

•  Asa  customer  concerned  with  the  effectiveness  of  its  contractors  in  teaming  to 
produce  affordable  weapons  systems  in  a  timely  fashion. 

In  these  roles,  the  DoD  is  a  customer  for  systems  and  tools  that  onable  streamlining 
and  change  management  and  which  are  effective  in  a  multi-enterprise  enviroranent  The 
DoD,  as  a  customer  for  information  and  systems,  can  help  focus  government-industry 
requirements  in  order  to  create  focused  market  pull. 

The  DoD  needs  to  be  a  part  of  a  larger  process  of  developing  information  tnfrasouc* 
ture  capabilities  for  enterprise  integration  along  with  commercial  industry.  Declining  bud¬ 
gets  dictate  as  cost  efficient  an  approach  as  possiUc.  ^ense  requiremenu  for  emerpnw 
integration  are  not  so  unique  that  they  drive  the  DoD  to  ■  unique  iitfraioucture  solotion 
The  advantages  to  be  gained  by  the  ability  to  acquire  capabilities  from  a  rcsponstve  open 
market  arc  considerable.  Conversely,  DoD  can  acceleraie  the  fonruMion  of  the  mvtey  w 
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ways  that  are  appropriate:  technology  push,  technology  and  practKe  demonsaauon. 
requirements  pull,  and  standardization  assistance. 

Principal  Finding? 

Extent  of  enterprise  integration  Companies  are  making  sigoilKayBi  vommiunmis 
and  executing  targe  efforts  toward  enterprise  iniegranon  SigniiKaAi  lesulis  ate 
achieved,  and  companies  now  realize  that  achies  mg  mure  is  leAsitOe 

Justification  for  enterprise  mtee/difon  JttsiiB».at*oAs  leporievl  fwi  it  eiwn 

prise  integration  tended  to  be  iniuiuve  expressed  m  lerms  or  wompruuse  acke-sM!>  auj  « 
sense  of  potential  quality  impruvemeni  anJ  vo*st  fcOwk-iiMn.  iaairr  Oka*  >.  ssi  {««• 

efit  analysts. 

|||Q{Q]g|l|jdji|ggQgl^  Mo*»t  <jt  Oic  vu<npi«aar»  sia»>ir*t  lae  aapsinwitniXik^  «n 
mental  "contmenis  of  mtegrafioft  «aanrg7  k.)  wippiii*-  aHagsaaK*  l^ikXcits  rUiS«ius«g 
thts  straiegy  a  genera'  Uwa  of  cxprcMrnkc  an*i  it-wmajai  rntrunv  t<.  mmc 
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vomptMues  vMiiMf  want  rmrnt  mtegraaed  mtltwtaNfciiiawr*  %Mm  tm  niiwi  Oe  tiinwnii'  nOsnaww 
ture  ta  viewed  m  a  ^nmer  to  tnacgraMM  «.b'«wNr>  and  ^nvaiwer  «»  a«<ei|iHK«d  aMHuinwtnww 
would  facitnaie  me  mfiwmmniw  mnnng  *»  wuwa  inega  awl  wUMamns  reftnid 
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accepted  standards,  all  are  proceeding  with  enterprise  integration  using  available  products 
and  technology,  developing  company-unique  solutions  where  needed.  Companies  that  are 
infrastructure  buyers  expressed  a  widespread  desire  for  appropriate  standards.  In  most  cas¬ 
es,  infrastructure  vendors  would  prefer  having  widely  accepted  standards. 

Lack  of  scientific  knowledge  and  accented  engineering  practice.  While  increasingly 
complex  integrated  systems  are  being  implemented,  the  understanding  of  scientific  and 
engineering  issues  inherent  in  such  systems  is  generally  weak.  This  understanding  can  be 
increased  through  continued  industrial  efforts  such  as  those  reported  in  this  study,  through 
demonstrations  of  new  approaches  in  realistic  settings,  through  academic,  government  and 
industrial  research,  and  through  development  of  new  integration  technology. 


Principal  Conclusions 

Organizational  limitations  of  current  approaches.  The  commonly  used  incremental 
“continents  of  integration”  approach  does  not  provide  for  evolvability,  thereby  incurring 
higher  costs  to  take  the  next  steps  in  integration.  Mechanisms  for  sharing  integration  expe¬ 
rience  and  for  identifying  common  successes  and  failures  are  lacking.  Methods  for  over¬ 
coming  cultural  barriers  to  integration  that  are  successful  for  intra-organization  integration, 
the  dominant  mode  to  date,  do  not  transfer  easily  to  inter-organizadon  integration. 

Technical  limitations  of  current  approaches.  Lack  of  standards  represented  in  avail¬ 
able  products  leads  to  locally  unique  solutions  to  integration  problems,  which  later  become 
obstacles  to  further  integration,  to  be  worked  around  or  converted  at  additional  cost  Formal 
standards  will  become  more  important  as  inter-organizadon  integradon  becomes  the  dom¬ 
inant  mode.  Lack  of  an  accepted  framework  or  reference  model  for  informadon  infrastruc¬ 
tures  makes  identifying  holes  and  overlaps  in  standards  coverage  extremely  difficult 

Enterprise  integradon  and  the  DoD.  In  many  senses  the  DoD  is  the  prototypical 
enterprise,  with  multiple  suppliers,  numerous  customer  programs,  highly  technical  and 
information-flow  dependent  products  and  processes,  people  and  operations  physically 
located  throughout  the  world,  and  a  complex  internal  organization.  The  DoD  has  much 
more  difficuh  hurdles  to  overcome  in  achieving  successful  integration  than  most  enterpris¬ 
es,  and  has  commensurate  potential  for  realizing  benefits  in  quality,  cost  reduction,  and 
responsiveness. 


Recommendations  •  Strategy 


Some  Defense  contractors  have  begun  to  re-engineer  business  processes  and  the 
information  systems  that  support  them.  The  key  ingredients  exist;  technologies  to  start  the 
process,  approaches  to  eliminate  barriers,  and  a  favorable  government  climate  for  infra¬ 
structure  investment.  DoD  and  the  Services  can  accelerate  industrial  inplementation  of  the 
required  processes  and  systems  through  four  strategies:  (1)  exerting  leadership  through  the 
use  of  the  National  Information  Infrastructure  (Nil)  initiative  and  joint  rapid-response  task 
forces  from  government  and  industry;  (2)  acting  as  an  informed  customer  of  informed  sup¬ 
pliers;  (3)  forming  parmerships  with  industry  to  support  and  accelerate  de  facto  and  emerg¬ 
ing  formal  standards  for  information  systems  interfaces  and  elements;  and  (4) 
demonstrating  and  advancing  technologies,  thereby  mitigating  the  risk  in  developing  high- 
risk  elements  needed  for  large-scale,  dynamic,  and  rapid  integration.  The  results  of  the 
fourth  strategy  would  be  to  advance  the  state  of  the  art,  provide  performance  results  as 
benchmarks  for  industry,  and  accelerate  technology  transition  into  the  information  manage¬ 
ment  marketplace. 

In  response  to  these  strategies,  two  types  of  implementations  should  be  applied, 
usually  simultaneously,  to  projects  started  in  response  to  any  specific  recommendation; 

•  l^th  incremental  implementations,  the  DoD  and  each  industrial  enterprise 
should  focus  first  on  part  of  the  process  that  the  enterprise  executes  and  then 
expand.  Incremental  Implementations  are  feasible  and  desirable  if  long-term 
evolvability  is  kept  as  a  critical  requirement.  For  example,  focusing  on  integrat¬ 
ed  product/process  development  (IPPD)  would  be  appropriate  if  plaimed  for 
future  expansion  into  other  enterprise  processes  such  as  logistics,  manufactur¬ 
ing  operations,  and  strategic  planning. 

•  With  c^plication'driven  implementations,  the  DoD  should  focus  on  product- 
type-specific  processes  first  and  then  generalize.  Implementation  strategies 
should  be  application  driven.  Past  efforts  have  shown  that  generic  approaches 
to  concepts  such  as  IPPD  are  seen  as  too  abstract  and  having  limited  success. 
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Speciflc  Recommendations 
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1.  Defense  Leadership 

1.1  The  Advanced  Research  Projects  Agency  (ARPA)  should  estab> 
lish  a  focus  area  for  industrial  information  integration  within  the 
National  Information  Infra^ructure  (NO)  initiative. 

The  Nil  initiative  can  enable  ARPA  to  prototype  and  demonstrate  the  capabilities 
required  to  address  the  compelling  national  issue  of  industrial  efficiency  and  effectiveness. 
Instead  of  using  application  areas  simply  to  motivate  underlying  technologies,  ARPA 
should  pay  considerable  attention  to  the  exploitation  of  the  infrastructure  by  industrial  users 
interested  in  leading  to  new  ways  of  doing  business.  These  new  industrial  uses  of  the  Nil 
will  simultaneously  stress  the  underlying  assumptions  of  the  prototype  networking  services 
and  help  U.S.  industry  understand  how  to  use  the  new  capabilities  to  maximum  advantage 
for  international  competitiveness.  The  result  will  be  a  better  and  more  immediately  useful 
Nil  and  a  more  efficient  U.S.  industrial  base  for  both  Defense  and  civil  purposes. 

1.2  DoD  and  the  Services,  working  with  industry,  should  establish  a 
consensus  vision  of  enterprise  integration  and  set  an  example  of 
integration  within  their  own  acquisition  processes. 

DoD  and  Service  acquisition  and  technology  organizations  should  stress  the  prior¬ 
ity  of  integrated  enterprises  and  integrated  information  systems  to  both  government  and 
industry.  To  make  this  credible,  DoD  and  the  Services  should  work  with  industry  to  set 
goals,  objectives,  and  characteristics  of  integrated  enterprises,  and  then  establish  a  phased 
program  to  both  re-engineer  government  acquisition  processes  and  integrate  supporting 
information  systems.  This  would  create  a  model  for  industry  and  provide  processes  and 
systems  to  which  industry  can  link.  Repeated  evidence  from  leading  companies  indicates 
that  sustained  commitment  by  the  Office  of  the  Secretary  of  Defense  and  Service  acquisi¬ 
tion  and  technology  executives  will  be  required  for  these  efforts.  Current  efforts  being  ini¬ 
tiated  within  the  Office  of  the  Undersecretary  of  Defense  for  Acquisition  can  provide  a 
basis  for  responding  to  this  recorrunendation. 
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2.  Informed  Customers  and  Suppliers 

2.1  DoD  and  the  Services  should  integrate  deliverables  within  both 
acquisition  and  technology  programs,  creating  incentives  to  moti* 
vate  industrial  process  and  information  system  integration. 

The  separate  functional  or  “stovepipe”  requirements  currently  typical  for  contrac¬ 
tual  deliverables  act  as  inhibitors  to  industry  information  system  and  process  integration, 
and  would  inhibit  Defense  use  of  well-integrated  civilian  industrial  capabilities.  In  support 
of  process  integration  efforts,  the  efforts  started  by  the  DoD  Computer-Aided  Acquisition 
and  Logistics  Support  (CALS)  program  to  dehne  integrated  weapons  system  data  bases  and 
Contractor  Integrated  Technical  Information  Services  should  be  accelerated  to  replace  cur¬ 
rent  separate  CDRLs  (Contract  Data  Requirentents  Lists)  for  separate  functional  areas.  Fur¬ 
thermore,  the  development  of  industrial  integrated  information  systems  should  be  an 
evaluation  factor  in  source  selections  and  an  explicitly  allowable  cost  for  internal  research 
and  development  (R&D)  and  implementation  phases. 

d:  it!  it!  ft!  til: 
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3.  Partnerships 

3.1  DoD  technology  organizations,  cooperating  with  other  interested 
federal  agencies,  together  with  leading  industrial  firms,  should  es¬ 
tablish  partnerships  to  develop  information  infrastructures  to 
support  int^rated  industrial  activities. 

Here  the  objectives  would  be  to  share  experience  on  implementation  approaches, 
metrics,  test  and  validation,  and,  where  appropriate,  to  share  the  risk  in  technology  devel¬ 
opments.  The  government  appears  willing  to  support  pre-competitive  industrial  coopera¬ 
tion  to  implement  industrial  information  infrastructures.  These  partnerships  should  be  as 
ffee  as  possible  of  federal  acquisition  constraints  so  as  to  enable  the  participation  of  firms 
that  do  not  normally  contract  widi  the  government  The  partnerships  should  be  built  within 
Advanced  Technology  Demonstrations  (ATDs)  and  the  Manufacturing  Science  and  Tech¬ 
nology  (MS&T)  pilot  programs,  or  similar  programs,  executed  in  settings  grounded  by  real 
applications.  DoD  should  evaluate  leading  company-^cific  infirastructure  implementa¬ 
tions  for  potential  DoD-wide  application  and  should  then  support  generic  information 
infrastracture  technology  developments  by  vendors  so  as  to  accelerate  availability  of  ven¬ 
dor-supported  products.  The  goal  would  be  to  shorten  lead  times,  from  feasibility  demon- 
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(3)  advanced  services,  where  some  integration  appKcatioos  might  best  be  executed  as  ser¬ 
vices  on  an  easily  accessible  network;  (4)  legacy  database  iniegration.  developing  near- 
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intelligent  agents;  and  (5)  persistent  object  brokerage,  extending  to  wide-area  applications 
so  that  wide-area  enterprises  can  be  more  easily  integrated. 

4J  DoD  technology  organizations  should  take  advantage  of  existing 
programs  and  industry  cooperative  efforts  where  appropriate. 

Several  programs  exist  with  potential  to  evolve  industrial  information  infrastruc¬ 
tures  for  integration.  The  topic  of  information  infrastructures  is  expected  to  be  a  significant 
part  of  the  Technology  Reinvestment  Project  (TRP).  Selection  and  management  of  TRP 
programs  should  follow  the  overall  strategy  outlined  here.  Because  of  the  high  leverage  of 
infrastructure  to  U.S.  design  and  manufacturing,  the  follow-on  to  the  current  TRP  should 
include  a  focused  dual-use  infrastructure  program  supported  jointly  by  ARPA,  Depart¬ 
ments  of  Commerce  and  Energy,  the  National  Aeronautics  and  Space  Administration 
(NASA),  and  the  National  Science  Foundation  (NSF).  The  Thrust  7  infrastructure  program 
(along  with  the  Agile  Manufacturing  Program)  could  provide  the  national  technology  lead. 

Where  applicable,  planno's,  developers,  and  demonstrators  should  use  forward- 
thinking,  existing  and  emerging  industry  cooperative  efforts  to  accomplish  required  indus¬ 
try  liaison.  This  implies  an  understanding  of  the  mechanisms  and  interests  of  various  types 
of  groups  such  as  technology  cooperatives  (e.g.,  the  CAD  Framework  Initiative  (CFI)), 
industry-government  cooperatives  (e.g,.  the  CALS  Industry  Steering  Group),  and  formal 
standardization  mechanisms  (e.g.,  ESPRIT  AMICE  consortium,  the  Object  Management 
Group,  the  ISO  STEP  committees,  and  the  sector-^cific  Automotive  Industry  Action 
Group). 
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GUIDE  TO  THE  REPORT 


Section  1  introduces  enterprise  integration  and  industrial  information  infrastruc¬ 
ture.  It  summarizes  the  DoD  task  directing  this  study,  with  pointers  to  particular  issue  dis¬ 
cussions.  It  highlights  progress  being  reported  in  enterprise  integration.  The  section  ends 
with  a  discussion  of  DoD  interests  in  the  subject. 

Section  2  discusses  the  current  state  of  industrial  enterprise  integration  as  captured 
in  visits  to  22  leading  companies  in  the  electronics,  automotive,  and  aerospace  sectors.  It 
begins  by  presenting  the  enterprise  integration  context  of  information  infrastructures, 
including  definitions,  objectives,  and  critical  factors,  followed  by  a  synthesized  case  study 
reflecting  current  best  practice.  It  discusses  reported  benefits  and  pitfalls  of  integration.  It 
next  discusses  the  DoD's  role  in  enterprise  integration  and  related  issues.  It  surveys  issues 
in  the  engineering  of  integrated  information  systems.  The  section  ends  with  a  brief  discus¬ 
sion  of  how  enterprise  integration  and  information  infrastructures  are  related  to  concnirrent 
engineering,  computer-integrated  manufacturing,  integrated  computer-aided  design,  and 
flexible  manufacturing. 

Section  3  presents  a  vision  of  future  industrial  enterprise  integration  suggested  by 
the  findings  jf  this  study.  The  vision  is  presented  from  two  perspectives:  first,  in  temu  of 
the  effect  of  information  infrastructures  in  the  year  2001.  and  second,  in  terms  of  the  tech¬ 
nological  developments  that  have  permitted  that  effect 

Section  4  is  a  summary  of  IDA  Document  D-I3fi6.  CurrtM  Standbnfrxatuwi  owf 
Cooperative  Efforts  Related  to  Industrial  Information  Inffastructuns.  which  contains  an 
extensive  baseline  analysis  of  standards,  technologies,  cooperative  efforts,  and  related 
(vganizations.  The  standards  and  technologies  are  grouped  into  techiucal  categories,  and 
are  related  to  the  organizations  and  programs  in  terms  of  deployment  actrvitiei  required  for 
successful  technology  development  and  market  building.  A  quality  function  deployment 
analysis  is  used  to  identify  which  standards  and  technologies  are  most  critical  to  succewful 
implementation  of  information  infrastructures,  and  to  assess  the  maturity  of  dicte  efforu 
The  ot^dves  of  the  baseline  report  are  to  identify,  organiie.  and  present  available  tech 
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nology  components  from  which  a  U  S.  informauon  iniegraiiufi  >craicg>  w  jji  Oc  cvVaicvrJ 
and  to  identify  specific  opportuntaes  to  at.celefaie  me  lie^ciopmeni 
ponents  and/or  to  increase  theu  likelihood  or  5*jccev» 

Section  5  presents  the  prmLipal  nnding^  and  \.onklu»ivMi>  or  i&e  GeuntL.  tuiO 
ings  are  given  in  more  detail  in  Appendix  A 
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•  Maiugenient  in/onmtiofi  systems  with  engineering  and  manufacturing  systems 

•  Defense  maintenance  and  logistics  systems  with  contractor  technical  informa¬ 
tion  bases 

•  Defense  customer  requirements  definition  with  conmetor  conceptual  engineer- 
wg  ' 
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iwpmtam  facior  m  acfitcvtng  imrgnird  acmiaes.  Eapett  opuuon  poinu  to  the  con^iany  of 
Ike  mm  tmme  m  an  mtonnation-bnied  cmctpnse  for  eaample.  unies: 


In  km  taamy  of  Iddd.  imms 


f  Idqq.  meten  and  depnrwtnat  wtll  ittse  lo  dunk  duouffi 
in  kmy  owe  10  nfiom  and  wfioi  mfomtiiion  dury  need  fiom 
dmi  of  dm  ■faramana  ntll  flow  nddwnys  and  acsoss  de- 
MM  «MMr%  The  imetmy  ei  1449  ntll  be  an  mfoimiooa  ner- 


Akmaa 


I  aw  anmapnng  10  CMonr  Of  nor  MdoimacMMk 
wiosand  10  snoot  dtgwn  TWy  sirw  dw 


Thin  bMOf  de  «aM.  de 
m  a  dwm  semodM  m 


n  km  OoO  Ml 
MNwhod 


es  expense  and  delay  for  the  DoD  customer.  But  the  rationale  for  integration  is  compelling. 
From  the  DoD  point  of  view,  the  best  solution  would  be  common  and  conventional  inter¬ 
faces,  allowing  all  systems  to  interoperate  when  required. 


Complexity  of  Products 

Besides  the  complexity  of  the  teaming  process,  there  is  the  complexity  of  the  prod¬ 
ucts.  One  reason  the  products  are  difficult  to  design  and  build  is  that  they  are  required  to 
push  the  state  of  technology.^  To  absorb  new  technologies  faster,  the  DoD  systems  devel¬ 
opments  need  a  more  flexible  and  adaptable  design  and  manufacturing  base  than  exists 
today.  Integrating  activities  and  information  allows  both  the  products  being  designed  and 
the  systema  and  processes  used  to  design  and  manufacture  the  products  to  evolve. 

DoO  products  are  not  only  technically  complex,  they  also  require  unusually  high 
rohttstnesx  In  dte  past,  uuktssy  and  government  have  depended  on  test  artd  inspection  to 
discaad  unm  that  anil  not  he  rohua  enough  in  the  field.  Now  we  know  that  robustness  can 
be  aebtevad  through  die  soaiegy  of  problem  avotdint.  implemented  through  integrated 
appNuchas  wch  as  concurrent  enginoennf  To  help  resolve  dte  complexity  problem,  every 
compMiy  vMiind  tn  dns  nudy  and  in  prevtens  hwonne  for  Defense  Analyses  (EDA)  studies 
on  consmunt  wfinnatinf  has  concluded  dHi  computers  can  be  used  ut  a  highly  cost-cffec- 
iiva  manner  to  he^p  anpiimenf  a  genomlkied  tnargraonn  crargy 
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the  required  surge  efficiently.  Being  able  to  develop,  store,  and  deliver  integrated  product 
and  process  designs  into  a  well-integrated,  flexible  manufacturing  operation  could  have  far- 
reaching  implications  for  DoD  capacity  and  surge  strategies. 

Intertwined  with  the  capacity  issue  is  the  problem  of  affordability.  As  the  govern¬ 
ment  has  to  make  hard  political  and  economical  decisions  on  which  systems  to  continue,  it 
will  become  more  important  that  systems  be  developed  in  an  environment  that  maximizes 
efficiency  of  development  and  production.  Each  system  program  will  be  required  to  address 
the  internal  efficiency  of  its  processes.  The  oveihead  structure  attributable  to  the  fragmen¬ 
tation  of  effort^  in  government  and  industry  can  be  addressed  in  terms  of  enterprise  inte¬ 
gration  and  the  information  infrastructure  that  supports  it.  (There  are  many  other  issues 
inside  the  affordability  problem  beyond  the  scope  of  this  study.) 

Beyond  the  issue  of  development  and  unit  production  costs,  there  is  the  life-cycle 
cost  issue.  DoD  systems  have  unusual  but  not  unique  life  ^ans.  Costs  that  are  magnified 
by  a  system’s  longer  life  span  include,  for  example,  the  maintaining  of  the  very  large 
amounts  of  data  required  to  repair,  rqtlace,  reproduce,  and  evolve  parts  of  the  system.  The 
DoD  organizations,  suppliers,  and  contiacuffs  involved  in  the  sustaining  the  effectiveness 
of  such  a  system  form,  in  effect,  a  very  large  enterprise  with  many  information  linkages 
required.  The  efficiency  of  this  kind  of  enterprise  can  be  no  greater  than  the  efficiency  of 
its  informatioo  flow.  With  the  existence  of  the  CALS  (Computer-Aided  Acquisition  and 
Logistic  Suppon)  tnitiaiive.  the  DoD  recognizes  that  there  are  intra-government  and  gov¬ 
ernment-industry  linkages  that  requiie  extensive,  more  integrated  computer  support  An 
important  point  is  that  this  internal  (to  the  Dt^)  information  infrastructure  must  be  con- 
nected  to  the  industrial  inforrandon  infrastructures  for  nuaxmnim  effectiveness.  At  the  same 
time,  gooemment  practices  must  be  adopted  to  ensure  that  government  access  to  industry 
dnia  does  not  become  intrusive  and  counter-productive. 

U  OBJECnVIS  or  THIS  STUDY 

IDA  was  tasked  by  the  DoO  to  study  information  infrastructures  for  enteiprise  inte- 
paiion,  facnaing  on  several  questions: 

WHy  COWyiRlO  mt  til  uwtyipouf 

•  Wh«  progress  leading  companies  are  making? 


•  What  the  key  issues  are  and  their  implications  for  DoD? 

•  What  progress  relevant  cooperative  and  standardization  efforts  are  making? 

•  What  is  the  vision  of  the  future  in  the  year  2001? 

This  report  provides  a  non-technical  description  of  the  current  state  of  information 
infrastructures  for  industrial  enterprise  integration  and  a  vision  of  integration  infrastruc¬ 
tures  in  the  year  2001 .  The  focus  of  the  study  is  the  relationship  between  information  infra¬ 
structure  and  the  integration  of  industrial  enterprises.  This  report  concentrates  on  best 
practices  within  leading  companies,  the  rationale  for  attempting  integration,  and  open 
issues.  The  intent  is  to  create  focused  discussion  around  the  important  issues  and  to  help 
build  a  comnxrn  understanding  of  the  subject,  thereby  creating  the  groundwork  on  which 
an  effective  DoD  strategy  for  enterprise  integration  can  be  based. 

The  information  presented  here  is  based  on  company  visits,  and  provides  the  start¬ 
ing  point  for  an  industry-government  dialogue.  The  end  objective  is  to  reach  a  consensus 
among  interested  governmental,  industrial,  and  academic  parties  as  to  the  nature  of  indus¬ 
trial  information  infrastructure  issues  and  the  potential  for  goverrunent  and  cooperative 
action.  Comments  on  the  document  should  be  communicated  directly  to  the  authors.^ 

13  APPROACH  AND  SCOPE 

The  basic  strategy  of  the  IDA  study  team  was  twofold: 

•  To  analyze,  from  the  points  of  view  of  both  industry  and  government,  the  sup¬ 
port  that  weO-integraied  information  infrastructures  can  give  to  achieving  legit¬ 
imate  business  goals. 

•  To  relate  this  support  to  die  major  issues  surrounding  the  creation  of  such  infra¬ 
structures. 

The  IDA  study  team  identified  22  leading  U.S.  companies  in  3  industry  sectors:  i 

electronics,  automotive,  and  aerospace  (see  Table  I },  concentrating  on  companies  that  have 
targeted  integration  as  an  important  objective.  The  team  visited  these  companies  to  find  out 
what  has  been  accomplished  in  integrating  activities,^  why  the  efforts  were  undertaken,  and 
what  is  the  potential  utility  of  industrial  information  infrastructures.  Two  additional  com-  < 

CoauMBU  fhouM  be  am  10  IndastrUlnfcvnuiiQnlnhaAnictures  Study.  Institute  for  Defense  Analyses/ 

CSBD.  1801 N.  Denawifd  Saeci,  Afexendria.  VA  2231 1. 

*  The  focw  of  die  smiy  ww  on  denionnrMBd  iMeiriied  activities  at  leading-edge  companies,  rather  thtti 
indnatiy-wide  practices.  ( 
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panics  interested  in  integration  per  se  were  also  interviewed.^  For  the  automotive  sector,  a 
panel  of  experts  was  convened  to  discuss  trends  and  rationale.  The  results  and  issues  dis¬ 
cussed  in  this  report  are  derived  from  assessments  of  those  visits  and  review  of  the  related 
literature. 

The  topic  of  information  infrastructures  for  enterprise  integration  is  new  enough 
that  its  scope  was  open  to  discussion.  Thocfore,  the  study  team  had  the  opportunity  to 
define  the  scope  of  the  study  as  it  explored  current  states  of  practice  and  trends  in  industry, 
government,  and,  to  a  lesser  extent,  the  research  world. 

Industrial  managers  arc  beginning  to  understand  the  need  for  increasingly  integrat¬ 
ed  activities.  However,  the  relationship  between  business  goals  and  technical  information 
strategies  has  not  been  articulated  in  a  widely  accepted  way.  An  early  objective  of  the  study 
has  been  to  articulate  the  connection  between  goal  and  strategy,  based  on  results  and  trends 
in  leading  industrial  examples.  Other  objectives  have  been  to  identify  the  best  of  what  has 
been  accomplished  and  to  understand  why  the  efforts  were  undertaken. 

The  report  is  studied  by  DoD  interest  in  securing  the  full  benefits  of  enterprise  inte¬ 
gration  for  the  we^)ons  acquisition  process.  The  findings,  conclusions,  and  recommenda¬ 
tions  are  directed  toward  that  interest 

lA  INDUSTRUL  EXPERIENCE 

The  conqMUiies  visited  were  selected  for  study  in  order  to  discover  the  best  practices 
of  industrial  integratitm.  The  electronics,  aeroq>ace  and  automotive  companies  visited  are 
listed  in  IhUe  1.  These  companies  reported  having  nrade  substantial  commitments,  both 
financial  and  cultural,  to  using  information  infrastructures,  and  they  reported  achieving  sig¬ 
nificant  results.  The  study  team's  assunqrtion  is  that  the  qrplicabiliQr,  of  both  the  commit¬ 
ment  found  in  these  companies  and  the  results  they  ate  getting,  to  broader  DoD  and  U.S. 
industrial  practices  can  be  assessed  by  the  reader. 


’  IheiiaegiBiioacoiniMHiiesirareElectionk  Dm  System  mdEMefpriaelni^faik)nlbduKdogies.Sev^ 
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Table  1.  Companies  Studied 


ELECTRONIC 

Digital  Equipment 
Corporation 

Motorola 

Texas  Instruments 

Hughes 

National  Semiconduc¬ 
tor 

Westinghouse 

IBM 

NeXT  Computers 

Intel 

Tektronix 

AEROSPACE 

Allison 

Lockheed 

Northrop 

GE  Aircraft  Engines 

Martin  Marietta 

Pratt  and  Whitney 

AUTOMOTIVE 

Qoss  and  Ttecker 

General  Motors 

Ryobi 

Ford 

Modem  Engineering 

SATURN 

Common  Themes  and  Issues 

The  study  found  numerous  common  direads  throughout  industry  and  government 
discussions  of  enterprise  integration  and  information  infrastructure.  These  can  be  grouped 
into  sevoi  categories: 

1.  Scope  of  enterprise  integration 

(exanq>le  issue:  using  integrated  information  infrastructures  to  manage  change) 

2.  Relationships  among  companies 

(example  issue:  integration  with  multiple  customers  in  the  absence  of  generic 
representation  or  produa  standards) 

3.  Relationships  within  companies 

(example  issue:  relationship  between  information  infrastructure  and  achieving 
a  dynamic  and  relatively  lean  management  structure) 

4.  Roles  and  objectives  of  information  infrastructures 
(example  issue:  approaches  to  dealing  with  legacy  systems) 

5.  Architecture  of  integrated  information  infrastructures 

(example  issue:  benefits  and  pitfalls  of  the  “continents  of  integration”  strategy) 
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6.  Role  of  standards  in  integrated  information  infrastructures 
(example  issue:  incorporating  “evolvability"  into  standards)*^ 


7.  State  of  technical  understanding  of  how  to  engineer  integrated  information 
systems 

(example  issue:  absence  of  widely  accepted  measures  of  progress). 

Progress  Reported 

Companies  visited  in  the  study  reported  savings  from  information-system  support¬ 
ed  integration  of  activities  in  the  form  of  cost  reductions,  cycle  time  reductions,  and  quality 
improvements.  Some  reported  results  are  very  broad:  they  refer  to  whole  enterprises  and 
are  measured  in  very  large  units.  Others  are  focused  on  small  parts  of  the  product  realiza¬ 
tion  process,  with  correspondingly  smaller  measures  of  success.  In  all  cases,  the  companies 
reported  that  savings  came  from  integration  projects  and  initiatives  in  the  sense  described 
in  this  report  Some  representative  results  are  summarized  in  Table  2. 


Table  2.  Improvements  by  Business  Function 


COST 

CYCLE 

QUALITY 

Enterprise 
Integration  and 
Streamlining 
(Overall) 

SATURN;  20%  acrasa  tfw 
boaid  tavinQs  (a«L). 

DEC:30%nCMftx>mCIM. 

CROSS  AND  TRECKER; 

30%  ralum  on  new  ime- 
gtalKJ  tyalom. 

PRATT  AND  WHITNEY: 
(aducSon  in  bid  savinso 

SIOM  in  ona  aiaa  and  $20M 
inanattwr. 

IMRTIN  MARIETTA:  radue- 
Son  of  aRMk  loroa  by  ovar 
40%whlabuainass 
inciaaaad  by  3%. 

NEXT;  product  Ntipped  in  11 
monSto,  S  manS»  before 
oompeStort. 

MOTOROLA;  cellular  prod¬ 
uct  cycle  reduced  50%. 

NATIONAL  SEMICONDUC¬ 
TOR: 

Sme  to  market  reduced  from 

2  years  to  9  monSw  in  tome 
oases. 

Engineering 
and  Design 

DEC:  90%  raducSon  in 
daaigndaM  admin  ouft  83% 
nalucSon  in  design  dMi 
ooonSnahira. 

MOTOROLA;  50%  redueSon 

In  design  cycle  for  products 
us^  ASICs. 

DMRTIN  MARIETTA, 
reduced  board  dsuslopment 
Itoratiotrs  from  ZS  to  1.5. 

DEC:  reduced  release  ver¬ 
sion  errors  to  zero. 

MARTIN  MARIETTA; 
reduced  from  4  changes 
perdraMPingto2.2. 

Tl:  reduced  mask  version 
ralaaso  errors  from  6  to  0 
($600,000  savings/yr.). 

Test  and  Mock- 
ups 

MARTIN  MARIETTA:  laduc- 
Son  tram  2,100  hours  to  900 
houm  engineering  Sfwe  far 
nwek-up. 

FORD;  on  Sack  ivHh  raduc¬ 
Son  of  physical  models  fey 

90%. 

NORTHROP:  intogratod 

CAD  led  to  error-free 
mook-up  of  many  B-2  aac- 
Sorts. 

See  IDA  Document  D-1386,  Current  Standardization  and  Cooperative  Efforts  Related  to  Industrial  Infor¬ 
mation  litfrastructures. 


Table  2.  Improvements  by  Business  Function 


Manufacturing 
EngioMring, 
process 
planning,  tool 
design 

Operations 

including 

materials 

management 


Tl:  90%  reduction  in  order 
entry  labor  for  mask. 

MARTIN  MARIETTA:  reduc 
tion  of  10  tool  designers  to  4 


FORD:  10-1S%  reducSon  in 
sheet  metal  operations. 

SATURN:  wrork  in  prooess 
reduced  from  S  days  to  30 
minutes. 

DEC:  reduced  assembly  line 
work  toroe  tram  250  to  70 
workers. 

GM:  increase  of  fraction  of 
inventofy  in  use  to  95% 


MOTOROLA:  time  to  bring 
up  complex  pager  manufac¬ 
turing  lifw  reduced  by  order 
of  magnitude  based  on  inte¬ 
grated.  reusable  software. 


MOTOROLA:  5-week  to  1- 
week  reduction  in  PCS  sup¬ 
ply  and  assan9>ly  cycle. 

FORD:  reduction  of  sheet 
metal  manufacturing  tima  by 
19%  with  improved  quality. 


Business  Oper¬ 
ations 


MOTOROLA:  purchasing 
dalirtquenciss  reduced  from 
25%  to  0.1%. 

NATIONAL  SEMICONDUC¬ 
TOR:  on-schedule  deKvaries, 
incraasad  from  88%  to  98%. 

DEC:  60-day  savings  in  part 
ordering  due  to  on-line  data 
base. 


Information 
Systems 
Design,  Imple¬ 
mentation 


Data  Genera¬ 
tion  and  Deliv- 

oy 


ASIC  *  A^^ICBbQi^'SpMiiG  bili^ 
CAO 

cat  •  Conpulir  Inlipniid  Mmii 
DEC  -  Oasa  EemmmI  Cwpen 


DEC:  $675,000  from  moving 
from  fiche  to  on-line  access. 


NOfnriROP:  reduction  of 
provisioning  list  release  from 
6  momhs  to  60  minutas. 


OM  -  Qmrat  Moron 
PCS  •  Pimnd  Orau*  Bond 
not  •  nown  on  kwooMOTl 
Tl  •  Tomo  IwoOmnonlo 


2.  THE  CURRENT  STATE  OF 
INDUSTRIAL  ENTERPRISE  INTEGRATION 


This  section  discusses  the  current  state  of  industrial  enterprise  integration  as  cap¬ 
tured  in  visits  to  22  leading  companies  in  the  electronics,  automotive,  and  aerospace  sec¬ 
tors.  Topics  covered  include  objectives  and  results  of  integration  activities,  critical 
management  and  technical  factors  in  information  infrastructures,  current  best  practice,  the 
E>oD's  role  in  achieving  information  infrastructures  for  enterprise  integration,  and  related 
efforts. 

Supporting  data  for  the  material  presented  here  is  in  Appendix  A,  and  is  based  on 
the  industry  rationales  found  in  Appendix  B,  Appendix  C,  and  Appendix  D,  as  well  as  the 
company  reports  found  in  Appendix  E. 

The  following  definitions  are  assumed  throughout  this  document.  These  definitions 
are  commonly  used  by  the  companies  and  individuals  involved  in  this  study. 

An  enterprise  is  a  collection  of  organizations  and  people  formed  to  create  and 
deliver  a  product  or  products  to  customers.  An  enterprise  may  span  more  dian  one  con^a- 
ny,  and  may  be  envisioned  as  a  value  chain  of  producers  and  consumers.  As  determiners 
of  the  need  for  and  characteristics  of  the  product,  end  consumers  are  a  part  of  the  value 
chain  and  so  of  the  enterprise.  This  study  concerns  enterprises  whose  products  are  designed 
by  engineers  and  are  rruuiufactured. 

An  activity  is  a  set  of  actions,  contiguous  in  the  value  chain,  that  are  executed  by  a 
suo-part  of  an  enterprise.  Activities  may  be  viewed  at  different  levels  of  granularity  (e.g., 
design  engineering  as  an  activity  or,  at  a  finer  granularity,  circuit  board  layout  as  an  activi¬ 
ty).  Activities  may  occur  solely  within  a  closely  coupled  set  of  organizations  (e.g.,  product 
testing)  or  all  over  the  enterprise  (e.g.,  accounting). 


‘  ^  A  ‘'value  chain”  is  a  set  of  linked  activities  that  process  materials  and  information  to  produce  a  usable  prod- 
ua.  An  activity  “adds  value”  when  the  increase  in  die  product’s  maiket  price  resulting  from  that  activity 
exceeds  the  ad^tiontd  cost  of  the  materials. 
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Activities  may  be  more  or  less  integrated  to  the  extent  that  the  agents  (people  and 
machines)  executing  them  can  work  together  as  a  unified  process.  Agents  within  integrated 
activities  can  negotiate  trade-offs  in  order  to  reach  a  common  objective.  Integrated  activi¬ 
ties  are  generally  characterized  by  intense,  integrated,  and  often  interactive  information 
flows.  As  an  example,  concurrent  engineering  is  more  integrated  than  sequential  engineer- 


Figure  1.  A  Comparison  of  Sequential  Engineering  and 
Concurrent  Engineering 


Enterprise  integration  is  the  process  of  achieving  the  smooth  and  effective  flow 
of  material  and  product  between  the  activities  of  an  enterprise,  often  through  the  removal 
of  organizational,  process,  and  informational  barriers.  Possible  barriers  include  changes  to 

From  the  Concurrent  Engineering  (CE)  Integrated  Product  Development  (IPD):  Guide  to  Understanding 
and  Implementation,  Draft,  May  28, 1993. 
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product  requirements  or  process  characteristics,  breaks  in  process  flow,  organizational 
boundaries,  and  blockage  of  access  to  needed  information. 

Information  is  data  with  meaning.  Information  has  form,  syntax  (rules  of  gram¬ 
mar).  semantic  content  (meaning),  and  pragmatic  content  (usage  attributes). 

An  information  infrastructure  is  a  structured  collection  of  information  system 
components  and  organization  processes  that  enable  the  flow  of  necessary  information  with¬ 
in  the  enterprise.  These  components  and  processes  may  include  various  computer  plat¬ 
forms,  networks  and  communications  systems,  application  programs,  product 
representations,  data  management  systems,  policies  and  practices,  shared  user  skills  and 
expertise,  process  models,  and  interfaces  among  these  elements. 

An  enterprise's  information  infrastructure  may  be  more  or  less  integrated  to  the 
extent  that  it  easily  supports  intense,  interactive  information  flows  with  minimal  transfor¬ 
mation  of  the  information.  The  more  integrated  the  information  infrastructure,  the  more 
efficiently  enterprise-wide  policies  can  be  deployed.  An  information  infrastructure  is  more 
or  less  modular  to  the  extent  that  changes  local  to  a  sub-part  of  the  infrastructure  can  be 
made  without  enterprise-wide  side  effects. 

2.1  OBJECTIVES  AND  RESULTS  OF  INTEGRATION  ACTIVITIES 

2.1.1  Objectives 

U.S.  companies  are  integrating  activities  because  they  perceive  integration  as  nec¬ 
essary  to  competitiveness  in  the  world  marketplace  of  the  1990s  and  beyond.  Commercial 
companies  are  compelled  by  time-to-market  considerations  which,  in  turn,  result  in  better 
technology  tracking  and  lower  costs.  Defense  companies  are  driven  by  the  decrease  in 
defense  business  opportunities  to  demonstrate  that  they  can  design  and  delivery  military 
systems  at  higher  quality  and  lower  cost  than  the  competition.  In  both  sectors,  having  more 
efficient  product  cycles — ^producing  products  demanded  by  the  market  in  less  time  or  at 
lower  cost — requires  attention  to  many  factors,  notably  the  quality  of  intermediate  products 
(for  example,  designs  and  production  plans).  Critical  large-scale  implementation  targets 
include  integrating  the  activities  of  marketing  and  design,  design  and  manufacturing, 
design  and  purchasing,  manufacturing  and  purchasing,  design  and  maintenance,  and 
finance  with  everything.  Having  an  integrated  information  infrastructure  is  key  to  achiev¬ 
ing  these  targets. 
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Con^MUiies  visited  in  this  study  want  more  integrated  infrastructures  both  because 
current  infrastructure  is  viewed  as  a  barrier  to  integrated  activities  and  because  a  more  inte¬ 
grated  infrastructure  would  facilitate  the  information  sharing  on  which  integrated  activities 
depend.  Typically,  they  reported  spending  more  (whether  in  design,  manufacturing, 
finance,  or  marketing)  to  get  information  systems  to  work  together  in  support  of  integrated 
activities  than  was  spent  on  the  systems  themselves.  The  related  effort  expended  to  main¬ 
tain  systems,  to  train  administrators  and  users,  and  to  support  translators,  all  due  to  a  frag¬ 
mented  infrastructure,  is  widely  viewed  as  a  waste  which  can  be  correctable  system-wide. 

Further,  the  information  infrastructure  is  viewed  by  many  as  mainly  a  mechanism 
for  the  support  of  change  management*^  The  message  received  during  the  study  was  that 
change  is  inevitable,  that  it  is  sometimes  quite  rapid,  and  that  the  information  infrastructure 
of  the  future  must  be  able  to  change  with  the  surrounding  environment.  It  must  support  both 
large  grain  and  fine  grain  change.  At  any  given  time,  the  information  system  products 
bought  to  implement  the  infrastructures  must  be  tailorable  to  each  enterprise  and  part  there¬ 
of,  a  means  of  achieving  change  over  time. 

The  information  infrastructure  can  support  change  only  if  the  infrastructure  itself  is 
smoothly  evolvable.  This  requirement  of  evolvability  applies  to  all  aspects  of  infrastruc¬ 
ture:  information  system  components  to  network  protocols  to  product  representations  to 
organizational  policies  and  practices  to  process  models  and  so  forth.  As  an  example,  a  new 
step  in  the  engineering  process  using  a  new  analytic  tool  would  result  in  a  change  in  the 
process  model  and  methodology  enforcement  part  of  the  operational  environment,  and  the 
new  tool  would  be  set  up  to  use  certain  existing  information  classes,  possibly  outputting  a 
new  type  of  information.  This  requirement  for  evolvability  and  tailorability  is  a  recognized 
issue,  and  one  on  which  some  of  the  companies  visited  have  made  progress. 

2.1,2  Benefits 

The  companies  reported  significant  benefits  realized  from  information-system  sup¬ 
ported  integration  of  activities.  Most  of  these  benefits  fall  into  the  categories  of  quality 
improvements,  cycle  time  reductions,  and  cost  reductions.  The  division  of  the  effects  of 
integration  into  these  categories  is  somewhat  artificial  since  they  are  interrelated  and  most 
integration  activities  yield  in^rovements  in  more  than  one  category. 


Various  notions  of  change  about  which  people  are  concerned  are  described  in  Section  2.2.1. 4  on  page  24. 
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As  an  example,  it  is  a  simple  but  fundamental  observation  that  improvement  in 
quality  reduces  the  need  for  rework  and  allows  increased  lot  sizes,  leading  to  improvements 
in  schedule  and  cost.  Texas  Instruments  reported  a  decrease  from  six  per  year  to  zero  in 
released  mask  version  errors.  This  quality  improvement  results  in  a  cost  savings  of 
$600,000  per  year.  Another  example  is  captured  in  the  following  chart  (2).  Here  the  reduc- 
don  in  engineering  change  orders  from  using  a  logically  centralized  computer-aided  design 
(CAD)  model  is  quite  clear. 

An  example  of  an  integration  effort  that  yielded  benefits  in  all  three  categories  is 
Westinghouse's  Electronic  Assembly  Plant  (EAP).  The  EAP  assembles  printed  wire  assem¬ 
blies  (PWA)  using  integrated  systems  to  automate  workstation  activities.  EAP  uses  both 
robotic  and  manual  workstations  to  achieve  flexibility.  The  PWA  Computer-Integrated 
Manufacturing  (CIM)  system  transforms  engineering  design  data  into  machine  control 
data.  The  Material  Accountability-Robotic  Kitting  system  automates  preparation  and  kit¬ 
ting  of  electronic  components  for  assembly.  The  Standard  Electronic  Assembly  System 


Months  after  initial  releases 

Figure  2.  Six  Recent  Aerospace  Projects:  Sustaining  Releases 
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(SEAS)  consists  of  insmion  robot,  Computer-Aided  Misccllaireous  Operations  (CAMO), 
and  Inspection  Data  Entry  (IDE)  workstations.  At  the  CAMO  station,  SEAS  provides  com¬ 
puter-directed  operator  assembly  when  manual  work  is  needed,  and  at  the  IDE  station 
SEAS  directs  consistent  PWA  inspection  and  captures  non-conformance  data.  Tbe 
improvements  achieved  and  projected  by  integration  in  the  EAP  arc  shown  in  Table  3. 


Table  3.  Westinghouse  Electronic  Assembly  Plant 


1981 

1983 

1985 

1987 

1989 

Yields  (first  time  through) 

33% 

45% 

65% 

85% 

90% 

Cycle  Time  (weeks) 

12 

8 

5 

3 

2 

Relative  Cost 

100% 

92% 

56% 

45% 

30% 

An  integrated  ir^ormation  ii^astructwre  enables  extending  integration  practices  up 
and  down  the  value  chain.  Several  companies  stated  tnat  they  were  working  with  suppliers 
to  extend  the  company's  integrated  systems  to  the  suppliers'  facilities.  For  example,  auto¬ 
motive  sector  companies  typically  require  their  suppliers  to  use  the  same  CAD  system. 
Representatives  of  several  companies  reported  best  success  with  suppliers  for  whom  their 
company  was  the  primary  customer.  A  side  benefit  of  being  integrated  with  one's  suppliers 
is  that  outsourcing  decisions  become  mostly  an  economic  and  capacity  decision,  as  integra¬ 
tion  will  have  removed  many  of  the  technological  barriers  that  might  otherwise  have  to  be 
considered. 

An  effective  information  infrastructure  enhances  information  sharing  and  flow, 
which  are  critical  ingredients  of  enterprise  integration.  It  allows  prompt  dissemination  of 
information,  subject  to  appropriate  access  control,  on  a  need-to-know  basis.  For  example. 
Digital  Equipment  Corporation  reported  reducing  design  distribution  time  from  three 
weeks  to  two  hours.  Further,  electronic  access  to  design  data  enhances  the  timeliness  of  the 
information.  A  manager  can  probe  for  the  needed  information  rather  than  have  to  wait  for 
a  report  to  circulate.  At  SATURN,  Martin-Marietta's  LANTIKN  facility,  and  NeXT  Com¬ 
puters,  there  are  capabilities  to  monitor  and  probe  the  status  of  manufacturing  lines,  in  real 
time,  from  remote  facilities. 

2.1  J  Reported  Results 

Some  of  the  reported  results  are  very  broad;  they  refer  to  whole  enterprises  and  are 
measured  in  very  large  units.  Other  results  are  focused  on  small  parts  of  the  product 
realization  process  with  correspondingly  smaller  measures  of  success.  In  all  cases,  the 
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conq>afiies  rq)oned  that  savings  came  from  integration  projects  and  initiatives  in  the  sense 
described  in  this  report  Some  results,  described  in  the  next  section,  are  categorized  by 
function  in  Table  2. 
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2.1  J.1  Cu6t  Savings 

•  SATURN;  an  independent  expert  estintated  20%  across-the-board  savings  due 
to  integration,  work-in-progress  inventory  on  power  train  line  reduced  from  5 
days  to  30  minutes. 

•  Texas  Instrurrtents:  90%  labor  reduction  in  order  entry  process  for  masks. 

«  Digital  Equipment:  38%  return  on  investment  (ROI)  from  CIM  DeeShop  on  a 
project;  3-S%  total  product  cost  reduction  on  a  major  product  line;  90%  reduc¬ 
tion  in  design  data  administration  staff;  83%  reduction  in  design  data  coordina¬ 
tors;  reduced  assembly  line  work  force  from  250  to  70;  $675,000  per  year 
savings  in  moving  from  microfiche  to  on-line,  electronic  archives. 

•  Pratt  and  Whitney:  $10  million  in  bid  savings  in  one  area  and  $20  million  in 
another. 

•  Martin-Marietta:  reduction  from  2, 100  hours  to  900  hours  engineering  time  for 
mock-up;  reduction  from  10  tool  designers  to  4. 

•  Cross  and  Trecker:  30%  internal  rate  of  return  (IRR)  on  new  integrated  system 
with  legacies  scrapped. 

•  Ford:  10-15%  cost  reduction  in  sheet  metal  production,  with  better  quality. 

2.13.2  Cycle  Time  Reductions 

•  NeXT  Computers:  went  from  concept  to  shipping  product  in  11  months,  5 
months  before  the  next-best  conq)etitor  shipped. 

•  Motorola:  50%  reduction  in  design  cycle  time  for  end  products  using  ASICs 
(Application-Specific  Integrated  CSrcuits);  5- week  to  1-week  reduction  in  PCS 
supply  and  assembly  cycle;  cellular  product  cycle  reduced  50%  with  target  to 
reduce  50%  again;  one  cellular  product  cycle  was  3  weeks;  time  to  bring  up 
complex  pager  manufacturing  line  reduced  by  an  order  of  magnitude  due  to 


Appendix  E  contains  repoits  on  all  companies  visited.  All  of  the  reported  results  were  taken  at  face  value. 
Virtually  all  of  them  are  estimates. 
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software  reuse  allowed  by  integration;  purchasing  delinquencies  reduced  from 
25%  to  about  0.1%;  achieved  best  order  release-to-ship  time  of  4.S  hours. 

•  National  Semiconductor;  in  selected  cases,  time  to  market  reduced  from  two 
years  to  nine  months;  on-schedule  deliveries  increased  from  88%  to  98%,  with 
target  accounts  increased  from  95%  to  100%. 

•  Digital  Equipment:  60-day  savings  in  part  ordering  via  on-line  database;  design 
distribution  time  reduced  from  3  weeks  to  2  hours;  achieved  best-time  20 
minute  cycle  from  filing  of  ECO  (Engineering  Change  Order)  to  installed 
change  in  mask  information  (average,  2  hours). 

•  Northrop:  reduction  of  provisioning  list  release  from  6  months  to  60  minutes. 

•  Martin  Marietta:  reduced  board  development  iterations  from  2.5  to  1.5. 

•  Ford:  14%  reduction  in  time  for  ^eet  metal  production  with  better  quality;  on 
track  toward  goal  of  reducing  physical  model  builds  by  90%. 

2.13.3  Quality  Improvements 

•  Texas  Instruments:  reduced  released  mask  version  errors  from  six  per  year  to 
zero  (worth  $100,000  per  error). 

•  Digital  Equipment:  reduced  released  version  errors  to  zero. 

•  Northrop:  integrated  CAD  led  to  first-time,  wror-free  physical  mock-up  of 
many  B-2  sections  (projecting  zero  physical  mock-ups  in  future);  same  result 
for  physical  design  of  electronic  missile  subsystems;  achieved  first-time  correct 
tube  bend  connections. 

•  Martin  Marietta:  reduced  from  4  changes  per  drawing  to  2.2,  with  target  this 
year  of  1.9  (each  decrease  of  0.1  is  worth  about  $6  million  per  year) 

2. 13.4  Capacity,  Productivity,  and  Other  Improvements 

•  NeXT  Computers:  project  factor  of  1 5  to  20  improvement  in  direct  manufactur¬ 
ing  labor  productivity  versus  benchmark  of  “typical”  workstation  manufacturer 
(in  sales  per  manufacturing  touch  laborer). 

•  Northrop:  increased  customer  interest  due  to  electronically  delivered  CDRLs. 

•  Martin  Marietta:  increase  in  total  business  from  $0.75  billion  to  $2.5  billion 
with  reduction  in  work  force  of  15,000  to  8,600  over  last  20  years. 
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•  General  Motors:  increase  in  fraction  of  inventory  actually  in  use  from  5%  to 
95%  P 

2.1.4  Pttfalls 

In  addition  to  the  benefits  discussed  above,  a  number  of  the  companies  reported  on 
pitfalls  encountered  in  their  progress  toward  creating  integrated  Information  Infrastruc¬ 
tures.  These  pitfalls  included  the  following: 

•  Effects  of  cultural  and  organizational  barriers  to  the  acceptance  of  enterprise 
integration. 

•  Perceived  threats  of  integration  practices  to  individuals. 

•  Failure  to  match  integration  efforts  to  organizational  goals. 

•  Development  of  enterprise-unique,  non-standard  integration  solutions. 

Even  when  integration  goals  are  technically  achievable,  integration  is  not  easy  to 
implement,  largely  for  cultural-organizational  reasons.  As  noted  above,  an  information 
infrastructure  can  enable  a  nuuiager  to  probe  the  status  of  manufacturing  lines,  or  to  gather 
other  metrics  such  as  the  number  of  engineering  change  releases.  Some  middle  managers 
are  concerned  that  increased  upper  management  visibility  into  day-to-day  activities  will  be 
counterproductive,  tempting  higher-level  managers  to  “interfere”  and  react  to  details  out  of 
context  On  the  other  hand,  some  high-level  managers  see  integration  information  infra¬ 
structures  as  enabling  a  decrease  in  management  structure.  And  others  see  the  downsizing 
of  management  as  enabling  enterprise  integration  through  the  elimination  of  empires. 

At  the  technical  staff  level,  personal  productivity  metrics  are  seen  as  intrusive  or 
threatening.  And  several  companies  voiced  concerns  about  the  willingness  of  workers,  par¬ 
ticularly  engineers,  to  follow  integrated  process  models. 

Existing  systems  present  both  a  technical  and  a  cultural  issue  that  must  be  dealt  with 
in  integrating  an  enterprise.  Frequently  these  systems  belong  to  an  organization  and  tend  to 
reinforce  organizational  structure.  Some  managers  see  enteipiise  integration  as  a  threat  to 
their  organization,  and  the  organizational  culture  will  strongly  oppose  any  integration 
project  that  eliminates  or  phases  out  their  system.  One  enterprise  integration  director 
observed  that  the  only  way  to  replace  some  systems  is  by  retirement 


Source:  Eiecironic  Data  Systems  interview. 
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Enteiprise  integration  is  not  to  be  pursued  for  its  own  sake  in  the  absence  of  strate- 
gic  goals.  A  well-integrated  company  can  still  make  wrong  decisions.  An  enterprise  must 
attend  to  the  effectiveness  as  well  as  the  efficiency  of  integration.  It  is  possible  to  become 
trapped  into  viewing  individual  integration  activities  as  ends  in  themselves.  Also,  integra¬ 
tion  and  automation  are  not  coextensive.  All  companies  recognized  that  the  automation  of 
a  faulty  process  is  dangerous.  Digital  Equipment  Corporation  representatives  observed  that 
most  automation  failures  were  ones  that  addressed  automation  without  integration. 

A  more  subtle  pitfall  arises  from  the  need  to  proceed  with  integration  even  in  the 
absence  of  clearly  desirable  standards  and  standard  practices.  Enterprise  integration  leads 
to  consistent  practices  across  the  enterprise.  To  do  so  requires  an  integrated  information 
infirastmcture  which  must  include  common  information  exchange  facilities.  These  informa¬ 
tion  exchange  facilities  could  be  based  on  official  standards  (or  ad  hoc  standards),  such  as 
product  data  representation  standards.  In  the  absence  of  such  a  standard,  certain  informa¬ 
tion  exchange  usage  must  be  adopted  by  local  convention.  No  company  visited  in  this  study 
was  waiting  for  a  standard  to  emerge  before  starting  to  integrate  activities.  As  standards  are 
developed  and  vendors  offer  tools  that  are  based  on  those  emerging  standards,  companies 
then  plan  to  adopt  them  within  their  infrastructures.  Adopting  emerging  standards  is  one 
manner  in  which  an  informadon  infrastructure  must  be  evolvable.  In  the  meantime,  com¬ 
panies  implement  local  '^standards’*  whose  presence  is  embedded  in  the  systems  created  by 
a  successful  integration  effort  Evolutionary  adoption  of  emerging  standards  must  deal  with 
these  legacies  as  well  as  those  from  “pre-integration”  times. 

In  summary,  the  reported  benefits  from  integrated  information  systems  emphasize 
improvements  in  quality,  cycle  time,  and  cost  achieved  through  more  timely  and  more 
complete  sharing  of  both  operational  data  and  successful  integration  practices.  The  report¬ 
ed  obstacles  and  pitfalls  reflect  resistance  to  integration  efforts,  misdirected  automation, 
and  the  new  “status  quo”  that  results  from  successful  but  limited  integration. 

2,2  CIUllCAL  FACTORS  IN  INFORMATION  INFRASTRUCTURES 

The  following  sections  focus  on  those  attributes  of  information  infrastructures  and 
of  the  process  of  creating  infrastnictures  that  were  identified  in  this  study  as  critical  factors 
in  achieving  integration. 
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2J2A 


Management  Factors 

Critical  management  factors  discussed  in  this  section  include  the  following: 


•  Start-Up  and  Sponsorship 

•  Transfer  Strategies  and  Mechanisms 

•  Inter-Company  Integration 

•  Make  or  Buy 

•  Metrics 


•  Larger  Islands  of  Integration 

•  Managing  Change  -  Flexible  Integra¬ 
tion 

•  Role  of  Cooperative  Efforts 

•  Use  of  Formal  Models 

•  Automation  and  Integration 


22.1.\  Start-up  and  Sponsorship 

All  large  6rms  studied  in  this  effort  started  their  integration  activities  internally  as 
a  means  of  both  exploiting  what  was  seen  to  be  a  competitive  advantage  and  reducing  over¬ 
head,  time  in  a  project,  staffing  —  in  other  words,  cost  Cost  was  particularly  evident  as  a 
driver  in  the  aerospace  firms  although  time-to-market  was  also  a  factor  in  the  commercial 
airplane  business.  In  the  commercial  electronics  firms,  time-to-market  was  seen  as  an  over¬ 
whelming  driver  because  of  the  rapid  pace  of  change  in  the  underlying  technologies.  In 
defense  electronics  firms,  cost  and  problem  avoidance  are  the  major  drivers. In  the  auto¬ 
motive  firms,  the  competitive  advantage  was  to  some  extent  viewed  as  arising  from  inter¬ 
nally  developed  product  design  systems,  and  integration  was  seen  as  a  way  to  use  those 
systems  as  leverage  to  achieve  quality,  cost  and  cycle-time  improvements. 

In  most  firms,  decisions  to  pursue  integration  were  based  on  intuition  and  compet¬ 
itive  benchnrarking,  the  companies  deciding  to  integrate  to  avoid  being  left  behind.  In  firms 
with  extremely  strong  quality  programs.  Motorola  for  example,  integration  was  seen  as  a 
way  of  reducing  errors  and  this  has  proven  out  in  practice.  In  most  electronic  firms,  inte¬ 
gration  was  initiated  from  the  middle  ranks  in  response  to  cost  and  schedule  objectives 
deployed  from  the  top.  A  group  of  peers  would  recognize  the  need  to  cooperate  and  share 
data,  and  would  propose  a  project  to  effect  their  integration.  However,  for  success  a  high- 
level  ^nsor  was  critical  to  the  task.  The  sponsor,  typically  a  president  or  vice-president, 
needed  to  be  in  the  common  chain  of  command  to  resolve  impasses  between  the  groups  and 
smooth  management  delays  occurring  between  the  project  management  level  and  the  spon- 


Some  people  have  expressed  the  need  to  insen  new  electronic  technologies  into  weipons  systems  more 
quickly,  but  the  defense  acquisition  system  has  not  yet  been  adjusted  to  focus  on  cycle  time.  Thus,  time- 
to-market  is  a  secondary  consideration. 
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sor's  level.  This  sponsor  tended  to  be  the  Least  Convnon  Manager  above  the  groups  to  be 
integrated. 

2J2.1^  Larger  Islands  of  Integration 

While  it  is  possible  to  abstractly  define  information  infrastructures  that  span  enter¬ 
prises,  what  is  actually  happening  is  driven  more  by  culture  and  the  nature  of  localized 
knowledge  than  by  abstract  technological  feasibility. 

Most  of  the  companies  studied  are  implementing  a  “continents  of  integration  and 
automation”  strategy  to  support  integration  goals.  They  were  moving  from  very  large  num¬ 
bers  of  loosely  coupled  activities  and  disconnected  information  systems  (“islands  of  auto¬ 
mation”)  to  a  small  number  of  large  islands  (“continents”).  This  implementation  strategy 
exists  even  where  there  is  strong  support  for  enterprise  integration  from  the  top.  There  are 
technological  and  cultural  reasons  for  this  approach,  but  it  may  have  drawbacks  that  the 
companies  using  it  have  not  yet  encountered. 

The  technological  reason  for  this  ^proach  has  to  do  with  the  availability  of  solu¬ 
tions  from  information  syster.n  vendors.  For  example,  an  enterprise  may  desire  an  integrat¬ 
ed  qyproach  to  CAD,  but  there  are  no  systems  in  the  open  markeq)lace  that  integrate 
electrical  and  mechanical  CAD.  Available  systems  that  help  integrate  one  domain  are  seen 
as  tremendous  improvements  over  current  practice,  and  so  are  used.  This  inherently  creates 
continents  of  automation. 

The  cultural  reasons  for  adopting  the  continents  ^roach  include  the  fact  that  in 
most  companies  the  oiganizations  best  suited  to  understand  the  processes  being  integrated 
are  within  the  organizations  themselves.  The  people  in  these  local  organizations,  fairly  or 
not,  view  corporate  or  other  cross-cutting  information  systems  groups  as  too  far  from  the 
local  problems  and  too  focused  on  short-term  objectives. 

Potential  drawbacks  to  “continents  of  integration”  approaches  reported  to  the  study 
team  have  three  bases:  investment,  consistency,  and  evolvability.  The  first  concern  is  that, 
having  invested  in  integration  within  several  large  entities,  it  will  be  very  difficult  to  justify 
the  cost  of  changing  the  resulting  systems  to  integrate  those  continents.  The  second  concern 
is  diat  a  hierarchy  of  coordinating  conrunittees  may  not  be  able  to  arrive  at  consistent 
qrproaches  across  large  con^ranies.^^  The  third  concern  is  that  these  continent-oriented 

Extreme  examples  can  be  found  in  the  DoD  where  some  negotiations  over  common  approaches  to  similar 
activities  and  infbnnation  among  the  military  services  have  spanned  decades. 


22 


information  systems  are  not  being  implemented  with  consistent  evolution  mechanisms,  so 
that  nuurying  two  systems  will  require  greater  initial  investment,  on-going  changes  will 
have  to  be  implemented  in  different  ways,  or  both. 

Many  company  representatives  felt  that  even  if  technological  solutions  that  support 
tailorable,  evolvable  integration  were  available  in  the  marketplace,  the  cultural  issues 
would  still  make  enterprise-wide  integration  difficult.  These  representatives  feel  that,  even 
when  the  potential  drawbacks  are  well  understood,  only  very  strong,  constant,  and  visible 
top  leadership  can  overcome  cultural  barriers  of  the  sort  they  encounter. 

In  defense  contractors,  integration  projects  are  often  project  oriented.  Contract-spe¬ 
cific  activity  is  normal  in  defense  contractors  due  to  the  inconsistent  nature  of  the  demand 
1)1  defense  products,  but  it  does  have  its  problems.  One  problem  with  the  contract-by-con¬ 
tract  approach  is  that  there  is  no  continuous  infrastructure.  The  infrastructure  resides  in  the 
knowledge  of  the  people  who  implemented  the  last  project  A  great  deal  of  start-up  invest¬ 
ment  must  be  supported  by  the  government  program  with  each  new  contract.  On  the  other 
hand,  it  is  in  die  government's  interest  to  have  integrated  activities  and  support  systems 
used  on  its  projects.  Indeed,  some  defense  projects  are  among  the  most  advanced  imple¬ 
mentations  of  integration  over  physically  distributed,  multi-company  engineering  and  man¬ 
ufacturing  teams.  The  Northrop-led,  multi-company  integrated  approach  on  the  B-2 
strategic  bomber,  for  example,  is  credited  by  some  as  making  the  project  feasible. 

22,13  Thuisfer  Strategies  and  Mechanisms 

For  companies  integrating  within  divisions  or  functions  rather  than  across  enterpris¬ 
es,  there  are  issues  of  knowledge,  culture,  and  technology  transfer  strategies.  One  common 
transfer  approach  is  the  multi-organization  committee.  These  committees  can  work  both  as 
idea  exchanges  and  policy  originators.  As  idea  exchanges,  best  practices  from  one  organi¬ 
zation  are  brought  into  anc  cher.  As  policy  originators,  best  practices  are  reformulated  and 
proposed  as  policies  to  top  management  for  adoption  and  deployment  Both  modes  of  oper¬ 
ation  are  widespread  in  large  U.S.  companies. 

Another  transfer  mechanism  is  based  on  employee  rotation.  There  is  increasing  use 
of  this  mechanism  in  U.S.  companies,  but  the  companies  visited  for  this  study  did  not  report 
widespread  use. 

In  some  companies,  transfer  of  best  practices  is  left  entirely  to  chance.  There  are 
instances  where  coordinated  visits  from  outside  parties,  such  as  during  this  study,  effected 
a  transfer  of  knowledge  between  divisions  of  a  company.  This  absence  of  planned  transfer 


may  be  evidence  that  top  management,  while  wanting  integration  within  divisions,  favors 
total  divisional  independence,  or  it  may  be  evidence  of  insufficient  attention  to  deploying 
policies  for  company-wide  integration. 

Use  of  information  technology  as  a  knowledge,  culture,  or  technology  transfer 
mechanism  is  being  considered  in  research  organizations,  but  is  not  widespread  except  in 
the  increasing  industrial  use  of  “expert"  or  “knowledge-based"  systems. 

2J2.1A  Managing  Change  and  Flexible  Integration 

Change  management  is  a  theme  that  appears  in  most  discussions  of  enterprise  inte¬ 
gration  and  information  infrastructure.  The  sorts  of  change  that  concern  people  range  from 
very  large  (e.g.,  reorganizing  the  company)  to  highly  focused  (e.g.,  adding  a  new  engineer¬ 
ing  tool).  The  future  will  bring  the  formation  of  ad  hoc  inter-organizadonal  teams  more  fre¬ 
quently.  Information  and  control  flows  will  change  in  both  the  human  and  mechanical  sides 
of  the  enterprise.  And  the  nature  of  the  information  will  change. 

For  example,  the  advent  of  new  ways  of  synthesizing  and  analyzing  designs  have 
already  changed  engineering  processes.  Yet,  in  typical  practice,  organizations  are  slow  to 
adapt  to  the  changes,  and  the  related  information  infrastructures  that  have  developed  are 
chaotic. 

For  the  integrated  enterprise  to  adapt  to  change  efficiently,  the  integration  approach¬ 
es  must  be  planned  with  change  management  as  a  fundamental  objective.  The  information 
infrastructure  itself  must  be  designed  for  change. 

There  is  also  a  potential  role  for  standards  in  change  management  If  there  were  a 
standard,  neutral  representation  for  a  particular  sort  of  information,  three-dimensional 
CAD  models  for  example,  then  a  new  tool  from  a  new  vendor  could  be  substituted  for  an 
old  one  without  having  to  translate  the  existing  data.  Also,  the  change  inherent  in  working 
with  a  new  parts  supplier  or  new  teaming  partner  might  be  eased  by  the  existence  of  stan¬ 
dard  representations  and  information  frameworics. 

Conversely,  increasingly  rapid  change  must  be  factored  into  the  approach  to  stan¬ 
dards  themselves.  Appropriate  representations  for  mechanical,  structural  objects  today  are 
not  the  same  as  ten  years  ago,  and  these  were  not  the  same  as  ten  years  before  that  These 
changes  are  very  rapid  in  some  fields  and  product  data  standards  are  not  keeping  up. 
According  to  companies  visited,  an  evolution  mechanism  must  be  devised  as  part  of  the 
structure  of  standards  and  not  just  as  part  of  the  bureaucratic  process  that  develops  the  stan- 
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dards.  The  companies  express  concern  that  such  structural  evolution  mechanisms  are  not 
being  developed  in  cunent  efforts. 

2.2.1.5  lnter>Company  Integration 

Outsourcing  is  increasing  in  almost  all  companies  visited  during  this  study.  For 
some  products,  commercial  and  military  aircraft  for  example,  thousands  of  suppliers  are 
involved.  In  the  automotive  industry,  development  and  supply  of  tooling  are  primary  con¬ 
tributors  to  product  development  cycle  time.  In  all  the  studied  industry  sectors,  electronics 
are  being  used  to  replace  mechanical  devices.  In  the  electronics  industry,  increased  use  of 
integrated  circuits  from  outside  suppliers,  especially  ASICs,  is  at  once  an  imperative  for 
competitiveness  and  a  source  of  schedule  risk. 

All  this  would  indicate  that  integration  initiatives  should  include  careful  consider¬ 
ation  of  how  to  include  suppliers.  While  such  consideration  was  reported  by  the  studied 
companies,  it  is  clearly  a  secondary  issue  to  most  of  them.  It  is  reasonable  to  conclude  that 
this  is  a  consequence  of  the  middle-out  and  bottom-up  approaches  to  integration  that  pre¬ 
dominate  in  these  companies  as  described  in  Section  2.2. 1.2. 

Three  kinds  of  exceptions  found  in  military  aircraft  development,  automotive  sup¬ 
plier  relationships,  and  exchange  of  electronic  simulation  models  reveal  interesting  points. 
In  recent  cases  of  military  aircraft  development,  teams  of  prime  contractors  have  joined  to 
execute  the  programs.  The  systems  being  developed  are  so  complex  and  so  integrated  in 
concept  that  integrated  design  activities  are  necessary  for  success.  In  these  cases,  common 
systems  have  been  adopted  and  acquired  as  platforms  for  information  infrastructures.  Sig¬ 
nificant  investments  have  been  made  to  implement  these  infrastructures  both  out  of  contract 
funds  and  from  company  capital.  Issues  that  have  been  dealt  with  in  these  efforts  include 
such  matters  as  establishing  common  bills  of  materials,  establishing  common  product  data 
representations,  and  inter-company  security.  One  key  issue  is  how  best  to  use  concurrent 
engineering  where  manufacturing  or  other  downstream  issues  in  one  company  affect  and 
are  affected  by  design  decisions  in  another  company.  This  is  still  an  issue  being  addressed 
in  complex  military  development  programs. 

Military  aircraft  development.  The  study  team  asked  an  electronics  executive 
whose  company  was  beginning  to  establish  more  integrated  relationships  with  its  suppliers 
whether  his  company  was  leading  the  suppliers  or  the  other  way  around.  He  replied  that  his 
company  was  leading  its  suppliers  except  for  those  suppliers  who  also  sold  to  the  automo¬ 
tive  industry.  This  evidences  the  effects  of  10  years  of  automotive  industry  effort  in  the 
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direction  of  working  to  integrate  better  with  its  suppliers.  Use  of  electronic  data  interchange 
(EDI)  for  purchasing  is  commonplace.  The  large  automotive  companies  have  been  bringing 
suppliers  into  the  engineering  process  in  a  concurrent  engineering  sense  for  about  8  years. 
Some  have  included  supplier  engineers  in  (^ality  Function  Deployment  (QFD)  exercises 
early  in  the  development  process,  and  there  are  reports  of  benefits  gained  by  including  out¬ 
side  manufacturing  engineers  in  car  design  teams. 

Automotive  supplier  relationships.  The  use  of  common  information  infrastruc¬ 
ture  has  progressed  in  the  automotive  industry  to  the  point  where  suppliers  are  using  CAD 
systems  that  are  coirunon  with  each  supplier.  There  is  some  controversy  about  whether  it 
would  be  advantageous  for  these  CAD  systems  to  be  based  on  publicly  available,  conunon 
interfaces.  These  interfaces  could  include  common  data  representations,  procedural  inter¬ 
faces,  frameworks,  or  modeling  methodologies.  From  the  point  of  view  of  some  automotive 
companies,  notably  Ford,  sustainable  strategic  advantage  can  be  gained  by  using  their  own 
proprietary  systems  and  requiring  that  suppliers  license  and  use  such  systems  on  projects 
for  that  company.  These  companies  feel  that  open  standards  are  too  slow  in  appearing  and 
may  compromise  system  performance.  The  cost  of  maintaining  such  a  system  can  run 
upwards  of  $10  million  per  year  and  forfeits  the  benefits  of  open-market  competition  to 
some  extent.^®  From  the  suppliers*  point  of  view,  this  approach  is  also  very  expensive.  One 
supplier  estimated  it  sustains  a  20%  user-engineer  inefficiency  cost  due  to  the  requirement 
to  use  sixteen  different  systems  for  its  various  customers.  That  is  in  addition  to  the  cost  of 
actually  having  to  support  the  systems  with  additional  staff,  capital  investment,  and  licens¬ 
ing  costs.  Some  automotive  companies  recognize  that  they  are  paying  part  of  the  cost  of 
that  inefficiency,  but  the  cost-advantage  balance  is  not  very  well  understood.  Thus,  the 
automotive  companies  are  of  divided  minds  on  the  issue  of  common  solutions,  but  their 
suppliers  are  in  favor  of  them. 

Exchange  of  electronic  simulation  models.  The  third  illustrative  exception  to  the 
general  finding  that  companies  are  concentrating  on  internal  integration  comes  from  model 
sharing  in  the  electronics  industry.  When  a  company  buys  an  integrated  circuit  from  a  sup¬ 
plier,  it  is  advantageous  to  have  access  to  a  simulation  model  of  that  circuit  as  well.  This 
amounts  to  design  information  sharing  because  the  simulation  model  contains  enough 
information  to  be  able  to  recreate  the  design.  The  model  must  also  have  well-defined,  or 


^  Outside  engineering  tools  are  sometimes  brought  into  the  proprietary  systems  either  by  interfacing  them 
with  the  company  data  using  a  translator  (typical)  cff  by  paying  the  tool  vendors  to  port  the  tools  to  the  pro¬ 
prietary  system  (uncommon  due  to  lack  of  programmers). 
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preferably  standard,  interfaces  so  that  it  can  be  used  in  simulation  and  analysis  of  the  circuit 
in  which  it  is  incorporated.  All  this  raises  many  issues  of  information  infrastructure  in 
microcosm.  For  example,  there  are  security  concerns  associated  with  the  design  informa¬ 
tion  included  in  the  model.  How  can  the  supplier  enforce  a  security  policy  on  the  user  in  a 
different  company? 

Another  way  in  which  this  industry  provides  an  interesting  exception  is  in  the  devel¬ 
opment  of  ASICs.  Here  it  is  common  for  design  to  be  the  result  of  intense  cooperation 
between  supplier  and  customer.  Otherwise,  a  working  end-product  would  be  very  unlikely. 
The  situation  is  unlike,  for  example,  the  relationship  between  an  aircraft  builder  and  its 
engine  supplier.  The  behavior  of  an  ASIC  is  much  harder  to  capture  in  a  limited  number  of 
measurable,  analyzable,  continuous  variables  such  as  engine  thrust,  vibration,  moments, 
and  weight  Thus,  the  industry  has  had  to  think  through  the  supplier-customer  relationship 
in  terms  of  an  integrated  approach,  including  support  tooling,  and  contracting  vehicles. 

2^.1.6  Role  of  Cooperative  Efforts 

There  are  dozens  of  efforts  to  create  common  approaches,  data  representations,  and 
system  and  application  interfaces  related  to  enterprise  integration  and  industrial  informa¬ 
tion  infrastructures.^^  . 

To  understand  the  role  of  these  efforts  in  current  integration  activities,  it  is  useful  to 
differentiate  between  several  kinds  of  efforts;  potential  standards,  official  standard  devel¬ 
opments,  existing  and  maintained  official  standards,  product-based  but  unofficial  standards, 
and  ad  hoc  support  groups. 

Many  of  the  companies  visited  take  potential  and  developing  standards  efforts  quite 
seriously  but  do  not  depend  on  them.  Representatives  from  user  companies  often  monitor 
and  sometimes  participate  in  die  development  of  standards,  but  most  of  the  effort  is  sup¬ 
plied  by  vendors  of  systems  that  might  incorporate  the  standards  once  developed.  Examples 
of  these  include  die  unofficial  CAD  Framework  Initiative  and  the  official  ISO  Open  Dis¬ 
tributed  Processing  efforts.  User  companies  will  begin  using  standards  as  they  become 
widely  available  in  products,  either  as  partial  results  or  more  complete  ones.  No  company 
visited  in  this  study  was  waiting  for  a  standard  in  order  to  start  integrating  activities. 


For  discussion  of  specific  efforts,  see  the  companion  publication.  E>A  Document  D-1386.  Current  Stan¬ 
dardization  and  Cooperative  Efforts  Related  to  Industrial  Information  Infrastructures. 
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Several  companies,  particularly  in  aerospace,  put  product  data  exchange  (PDE) 
standardization  as  a  top  priority  item  for  recommended  government  support  Those  com¬ 
panies  all  felt  that  an  organizing  structure  or  macro-architecture  was  lacking  in  current 
efforts,  and  that  the  absence  of  such  an  organizing  structure  would  inhibit  integration. 

Use  of  existing  standards  is  variable,  ranging,  for  example,  from  partial  use  of  the 
International  Graphics  Exchange  Specification  (IGES)  for  drawing  exchange  in  parts  of  all 
three  industries  studied  to  virtually  universal  attempts  to  use  the  SQL  standard  for  relational 
databases. 

One  factor  in  the  success  of  a  standard  is  whether  its  implementations  are  validated. 
The  user  community  always  says  it  wants  validation,  but  it  is  often  unclear  who  is  willing 
to  pay  for  the  development  and  execution  of  validation  processes.  There  is  a  potential  gov¬ 
ernment  role,  but  the  criteria  for  government  investment  in  validation  must  be  formulated. 

Product-based  unofficial  standards  are,  by  definition,  widely  accepted  within  the 
donudn  in  which  they  are  considered  standards.  That  domain  may  be  a  single  functional 
organization  within  a  company  or  it  may  be  a  national  user  group.  This  sort  of  standardiza¬ 
tion  does  not  really  depend  on  cooperative  efforts  except  in  the  sense  that  the  system  vendor 
and  its  more  influential  users  determine  cooperatively  the  evolution  of  the  system.  Never¬ 
theless,  proprietary  solutions  should  not  be  ignored.  There  is  the  possibility  that  official 
standards  could  be  developed  based  on  them  if  there  is  enough  community  support,  partic¬ 
ularly  from  users.  For  such  an  effort  to  produce  results  quickly,  a  deliberate  plan  must  be 
executed  to  converge  on  a  result  that  will  be  seen  as  in  the  interests  of  the  competitors  of 
the  original  product  as  well  as  its  originator. 

The  last  kind  of  cooperative  effort  is  the  ad  hoc  support  group.  Such  groups  are  gen¬ 
erally  composed  of  representatives  of  user  companies  pushing  for  convergence  on  a  profile 
of  standards  to  be  implemented  in  a  broad  array  of  products.  It  is  beyond  the  scope  of  this 
study  to  determine  what  is  required  to  make  such  a  group  successful. 

2.2.1J  Make  or  Buy 

Every  large  company  seeking  to  create  integrated  information  systems  faces  a  make 
(build)  or  buy  decision.  Most  compaiues  want  to  use  a  collection  of  licensed  software  con¬ 
sisting  of  database  management  systems,  tools  for  computer-assisted  design  (CAD), 
engineering  (CAE),  software  engineering  (CASE),  production  planning  (CAPP),  manu¬ 
facturing  (CAM),  and  so  forth.  The  companies  must  decide  whether  to  make  or  buy  the 
integrating  environment  in  which  these  tools  operate  and  interoperate.  A  useful,  static  set 
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of  tools  and  databases  can  be  interfaced  and  integrated  for  a  few  million  dollars.  An  indus- 
trial-strengui  framework  that  acconunodates  the  integration  and  evolution  of  a  dynamic  set 
of  tools  appears  to  cost  upwards  of  a  $100  million  to  develop.  On-going  maintenance  can 
cost  $10  million  per  year. 

The  choice  to  make  offers  a  greater  possibility  to  integrate  the  tools  very  tightly, 
particularly  if  the  tools  themselves  are  developed  in  house  as  well.  Even  with  licensed  tools 
it  is  possible  to  negotiate  access  to  their  data  structures  in  order  to  integrate  them  into  a 
coherent  system.  The  choice  to  buy  offers  the  advantages  of  selection  in  a  competitive  mar¬ 
ket,  with  the  v-  ndor  responsible  for  finding  and  making  productive  those  rare  people  capa¬ 
ble  of  successfully  implementing  an  evolvable,  open,  integrating  environment.  Buying 
increases  the  probability  of  reasonably  easy  integration  with  a  teammate  or  subcontractor. 
And  it  shares  costs  with  other  buyers  of  the  system.  Most  companies  indicated  that  buying 
is  cheaper.  Among  the  companies  studied,  buying  is  the  usual  approach. 

2.2.1.8  Use  of  Formal  Models 

Process  and  information  modeling  efforts  were  reported  at  several  companies  visit¬ 
ed  in  this  and  previous  related  studies.^  Many  people  involved  in  activity  and  information 
integration  efforts  regard  modeling  as  a  central  integration  tactic.  These  kinds  of  modeling 
are  not  widely  understood  outside  the  information  science  community.  Yet  several  compa¬ 
nies  reported  significant  process  and  information  modeling  efforts  with  various  objectives, 
approaches,  and  levels  of  success. 

Process  models  (descriptions  of  a  collection  of  interrelated  activities)  have  been 
used  to  establish  a  formalized  picture  of  what  goes  on  in  various  activities  in  a  company. 
They  can  be  used  to  redesign  and  streamline  prot^sses,  to  define  mandated  or  preferred  pro¬ 
cedures  for  both  operational  and  training  uses,  and  to  plan  for  support  activities  and  systems 
including  information  systems.  Process  models  are  commonly  used  to  design  computer 
programs.  In  a  sense,  all  computer-based  simulations  contain  process  nxxlels  as  well. 

Process  modeling  efforts  can  be  used  to  create  large,  centrally  controlled  models,  or 
the  efforts  can  be  very  distributed  and  localized.  Models  reported  in  this  study  as  used  for 
integration  and  training  purposes  tended  to  be  centralized.  Models  used  purely  for  process 
improvement  were  often  very  local. 

^  Linn,  J.  and  Winner,  R.  The  Department  of  Defense  Requirements  for  Engineering  Information  Systems 
(EIS)  Volume  1:  Operational  Concepts  (NTIS  AD-A176  153)  and  Volume  II:  Requirements  (NTIS  AD- 
A176  154).  IDA  Paper  P-1953,  Institute  for  Defense  Analyses,  Alexandria,  VA,  1986. 
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Models  used  to  help  define  new  support  systems,  especially  information  systems, 
tend  to  be  very  formal.  The  people  responsible  for  development  of  new  software  hope  that 
a  formal  model  of  the  encompassing  processes  will  drive  the  definition  of  accurate  software 
requirements.  While  such  modeling  does  help,  there  is  a  school  of  thought  that  anything 
that  claims  to  develop  accurate,  dependable  software  requirements  is  an  illusion,  and  there¬ 
fore  dangerous. 

Some  companies  report  another  potential  pitfall:  viewing  the  modeling  process  as 
an  end  unto  itself.  Arbitrarily,  large  efforts  can  be  expended  trying  to  make  models  even 
more  accurate,  particularly  when  the  processes  being  modeled  are  not  static  or  are  too  com¬ 
plex  for  anyone  to  grasp.  It  is  imperative  to  keep  the  purpose  of  the  modeling  exercise  clear¬ 
ly  in  sight  of  the  modelers  and  to  ensure  that  the  modeling  approach  is  suited  to  the 
objective. 

Information  models  (descriptions  of  the  form,  categories,  and  meanings  of  a  collec¬ 
tion  of  interrelated  information)  are  typically  used  in  the  development  of  information  sys¬ 
tems.  These  models  describe  the  kinds  of  information  used  in  company  activities.  The 
information  model  often  includes  information  that  is  not  and  never  will  be  in  a  computer. 
Most  of  the  models  include  information  flow  in  the  enterprise  and  thus  may  be  tied  to  a  pro¬ 
cess  model. 

The  set  of  definitions  of  the  meaning  of  information  that  is  included  in  an  informa¬ 
tion  model  can  be  used  as  kind  of  data  dictionary  for  various  activities.  The  extent  to  which 
a  model  should  and  can  capture  meaning  in  order  to  be  useful  to  human  users  is  not  well 
defined.  Nevertheless,  some  successes  have  been  reported. 

2.2.1. 9  Metrics 

Process  metrics  are  increasingly  used  in  industry  for  more  than  their  traditional 
applicatior  cn  the  factory  floor.  The  most  extensive  use  encountered  in  this  study  is  the 
Motorola  Six  Sigma  program,  a  corporate  program  to  reduce  the  error  rate  in  all  corporate 
processes  to  fewer  than  four  errors  per  million  opportunities. 

Other  process  measures  that  could  be  applied  to  enterprise  activities  include  trans¬ 
action  throughput,  response  time,  and  transaction  cost.  Although  the  results  listed  in  Sec¬ 
tion  2. 1 .3  are  not  reported  within  a  commonly  accepted  framework  of  process  metrics,  most 
could  be  regard  as  either  throughput,  response,  or  transaction  cost. 
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Another  measure  considered  indicative  of  process  quality  is  the  change  history  of 
process  products.  Cumulative  releases  of  a  product  over  time  (e.g..  Figure  2.)  is  an  example. 

Given  the  locality  of  most  metrics,  an  important  issue  is  how  the  measure  becomes 
usefully  visible  to  higher  levels  of  management  or  to  peers  in  an  integrated  enterprise. 
Today's  hierarchical  management  structure  makes  relatively  straightforward  roll-ups  of 
data  ir  handled  by  humans.  Automated  data  capture,  filtering,  reduction,  and  presentation 
is  a  promising  field.  Some  have  noted  its  similarity  to  military  C^l  data  fusion,  and  there 
could  very  well  be  dual-use  technology  developed  to  help  solve  this  problem.  Current 
examples  of  capabilities  to  monitor  and  probe  the  status  of  manufacturing  lines  from 
remote  facilities  can  be  found  in  all  three  sectors  in  this  study.  The  application  of  this  idea 
to  other  activities  besides  manufacturing  is  viewed  by  some  as  enabling  a  leaner  organiza¬ 
tion.  This  appears  to  be  an  important  potential  focus  for  industrial  information  infrastruc¬ 
ture. 


2.2.1.10  Automation  and  Integration 

Although  much  of  this  report  concentrates  on  automation,  integration  and  automa¬ 
tion  are  not  coextensive.  All  companies  recognized  that  automation  of  faulty  processes  is 
dangerous.  It  is  dangerous  because  it  can  make  the  process  worse,  because  it  diverts 
resources  that  could  be  used  to  make  the  process  better,  and  because  it  can  create  an  invest¬ 
ment  that  is  then  difficult  to  discard,  making  the  faulty  process  permanent. 

Integration  can  occur  in  some  instances  without  automated  support.  It  used  to  be 
commonplace  to  say  that  the  new  process  must  be  designed  first  and  then  automation  con¬ 
sidered.  This  is  usually  no  longer  true,  first,  because  of  the  scale  of  integration  being  con¬ 
sidered  at  leading  companies  and  foreign  competitors,  second,  because  of  tiie  increased 
effectiveness  per  dollar  of  automation  platforms,  and  third,  because  it  violates  the  princi¬ 
ples  of  integrated  solutions.  Given  the  state  of  technology,  one  should  plan  integrated  pro¬ 
cess  concurrently  considering  the  potential  automated  support  This  does  not  say  that 
evoything  should  be  automated.  It  does  say  tiiat  the  evidence  from  leading  firms  visited 
indicates  that  automation  is  an  inherent  part  of  most  successful  integration  solutions. 

2.2  J  Technical  Factors 

Critical  technical  factors  discussed  in  tiiis  section  include  the  following: 

•  Heterogeneous  Environments  •  Integration  vs.  Interfacing 

•  Open  Systems  •  Legacy  Systems 
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•  Frameworks  •  CASE  Frameworks 

•  Formal  Models  •  Security  and  Protection 

2.2 J.1  Heterogeneous  Environments 

Most  companies  currently  have  many  different  kinds  of  computers  running  many 
kinds  of  software  with  different  communications  networks.  This  is  true  in  many  companies 
even  for  systems  of  like  applications.  Such  heterogeneity  effectively  blocks  direct  integra¬ 
tion  of  information,  requiring  significant  additional  expense  to  make  information  in  one 
system  available  to  another.  At  the  companies  visited  for  this  study,  this  problem  is  being 
addressed  largely  by  adoption  of  common  platforms  and  software  environments  for  each 
“continent  of  automation.”^^  The  problem  of  heterogeneous  systems  is  to  a  large  extent 
being  avoided  by  switching  to  homogeneous  systems  where  possible.  Users  are  pressuring 
system  vendors  to  extend  the  scope  of  their  systems  where  possible,  and  it  is  often  in  the 
vendors'  interests  to  respond  favorably. 

Four  approaches  have  been  proposed  to  dealing  with  heterogeneous  systems; 

•  a  standard  middle  layer  of  interface  software 

•  a  set  of  information  exchange  standards 

•  a  standard  set  of  platform  interfaces 

•  a  standard  metamodelling  technology  for  heterogeneous  systems. 

The  approach  of  installing  a  middle  layer  of  software  that  provides  a  common  inter¬ 
face  to  applications  software  was  not  in  evidence  at  any  company  visited  for  this  study.^ 
Most  of  those  supporting  efforts  to  create  a  widely  adopted  set  of  information  exchange 
standards  have  come  to  recognize  that  such  standards,  to  be  effective,  must  be  developed 
in  concert  with  solutions  to  operational  environment  issues.  A  few  of  the  corrqranies  visited 
expressed  strong  support  for  such  efforts  aixl  appear  to  be  including  them  in  long-range 
planning.  The  idea  of  creating  standards  for  platform  interfaces  assumes  that  applications 
will  see  the  same  operating  system  services  and  interfaces  regardless  of  what  machine  is  in 
use  underneath.  While  user  companies  wish  that  this  were  the  case,  not  many  are  planning 


^  Furtier  dtscunkM  of  ~coMiMnts  of  aoiomahon'*  is  found  in  Section  2.2. 1.2. 

^  lliere  «e  examples  of  places  using  a ’'middlewwe”  ^iproich  to  imcffwion.  bM  dK  evidence  of  diis  sM 
is  dM  the  notion  lias  not  peneinsed  industry  very  weU.  One  example  is  the  Smahsonian  Oteervawy.  Cam* 
bridte.  Massmhusetts.  whkli  uses  the  ANSAwme  product  devdoped  withm  the  Eivopem  ESPRIT  pro- 
fimi.  The  Observaiary  is  reported  to  use  the  ptodmi  to  insegiaie  a  system  with  over  3000.  users  on  several 
different  kinds  of  computers. 
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on  it.  The  metamodcl  approach,  in  which  high  level  models  of  heterogeneous  systems 
would  drive  interfacing  software  enabling  unlike  systems  to  interact,  is  a  very  advanced 
approach  not  visible  on  the  planning  horizons  of  the  companies  visited. 

2^  J.2  Integration  vs.  Interfacing 

Systems  are  integrated  to  the  extent  they  can  interact  without  translation  of  proce¬ 
dural  interfaces  or  data.  Systems  can  be  interfaced  by  using  extensive  translation.  Several 
companies  reported  that  their  integrated  “continents  of  automation"  contained  a  great  deal 
of  interfacing.  Others  are  making  a  serious  effort  to  build  integrated  systems  from  the  data¬ 
base  out.  establishing  fixed  information  representations  and  reprogramming  tools  to  use 
those  representations.  Yet  others  depend  on  the  commercial  strength  of  their  common  sys¬ 
tem  vendors  to  cause  applications  vendors  to  integrate  with  the  large  common  systems. 

Even  those  considering  middle-layer  approaches  to  integration  of  heterogeneous 
systems  state  that,  for  the  foreseeable  future,  some  systems  will  have  to  be  interfaced  to  the 
logically  central  infrastructure  rather  than  integrated  into  it  This  conclusion  is  based  on  the 
existence  of  legacy  systems  and  databases,  performance  issues,  aird  market  forces. 

2J.2.3  OpcnSystcim 

In  an  open  system,  definitions  of  the  architeemre  and  interfK«s  are  widely  pub¬ 
lished  and  stable,  so  that  new  software  and  hardware  can  be  integrated  with  the  system  by 
many  people,  for  example  tool  vendors.  In  contrast,  a  closed  system  is  one  in  which  the 
architecture  and  interfaces  are  controlled  by.  and  so  understood  and  changeable  by,  a  small 
group. 

At  first  view,  open  systems  seem  most  desirable  for  int^raiion.  However,  openness 
itself  does  not  guarantee  applicabUtty.  Microsoft  MS/DOS.  arguably  the  most  successful 
open  system  in  the  history  ci  information  systems,  is  inadequate  for  nuny  engineering  and 
manufacturing  applications. 

Other  issues  are  cost,  performance,  and  timeliness.  With  an  open  system,  costs  of 
changes  in  platform  are  paid  by  the  user  community.  When  a  user  chooses  a  closed  system, 
porting  costs  arc  paid  by  that  user.  Standardized  approaches  to  evolvable.  tailorable  infia- 
structure  components  have  not  yet  achieved  the  levels  of  performance  required  fm  maximal 
integration.  It  should  always  be  possible  to  design  a  custom  system  that  integrates  needed 
applications  and  outperfomw  an  open  system. 
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Over  time  this  advantage  may  be  obviated  by  the  ability  of  the  marketplace  to 
respond  to  performance  demands  on  open  systems.  If  the  time  for  the  marketplace  to 
respond  becomes  less  than  that  required  to  develop  and  maintain  custom,  closed  systems, 
then  there  will  no  longer  be  a  performance  vs.  openness  trade-off.  However,  the  start-up 
time  for  establishing  open  systems  (other  than  those  based  on  de  facto,  market-based  stan¬ 
dards)  is  currently  too  long.  Open  systems  appear  only  in  the  long-range  plans  of  compa¬ 
nies  visited  for  this  study. 

2.12,4  Legacy  Systems 

Legacy  information  systems  are  existing  collections  of  activities,  machines,  com¬ 
puter  programs,  and  databases  that  may  not  ht  well  with  an  organization's  new  plans  and 
initiatives.  Legacy  systems  have  some  continuing  value  to  people  or  operations  within  an 
organization,  aiul  they  exist  in  all  but  new-start  organizations  (which,  if  successful,  develop 
their  own  legacies). 

Companies  report  three  ways  they  are  dealing  with  legacy  information  systems 
(other  than  doing  nothing):  interfacing  via  translators,  system  duplication,  and  replacement. 
The  extent  of  the  problem  can  be  considerable.  One  large,  but  not  huge,  company  reported 
having  six  hundred  incompatible  databases.  Such  databases  are  difficult  to  integrate 
because  they  have  many  transaction  routines  coded  into  the  database  management  system. 
These  routines  run  very  fast  and  are  hard  to  replace  with  systems  where  transaction  routines 
are  more  visible. 

One  approach  to  integrating  legacy  systems  is  to  encapsulate  the  database  system 
with  a  translator  that  makes  the  system  more  amenable  to  integration.  This  is  expensive 
because  the  translators  are  often  very  large,  error-prone,  difficult  to  maintain,  and  carry  a 
possibly  unacceptable  performance  penalty. 

Another  approach  is  to  duplicate  the  functions  of  the  system  in  a  new  technology 
more  amenable  to  integration.  This  can  make  sense  where  old  programs  are  too  expensive 
to  replace  and  where  they  already  satisfy  the  needs  of  the  organization  very  well.  New 
{q)plications  are  implemented  on  the  duplicate  (shadow)  database  and  old  applications  con¬ 
tinue  to  run  on  the  original.  In  some  cases,  the  plan  is  to  keep  both  systems  forever.  This 
q)proach  is  reasonable  unless  the  maintenance  cost  of  the  older  system  is  too  high  for  its 
value  to  the  company. 

A  third  approach,  relatively  unusual  in  companies  that  have  large  legacy  systems, 
is  to  replace  old  systems  with  easier-to-integrate  new  systems.  Key  issues  are  availability 
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of  capital  and  people  to  implement  the  new  systems.  The  cost  of  software  and  data  conver¬ 
sion  can  be  very  high. 

In  any  case,  dealing  with  legacy  systems  is  expensive.  Any  approach  should  be 
based  on  a  plan  for  evolution  that  decreases  the  risk  of  being  in  the  same  situation  again  in 
a  few  years. 

1J.2JS  Frameworks 

The  word  framework  is  widely  used  in  describing  information  systems,  but  refers 
to  differing  concepts  and  components.  For  purposes  of  this  discussion,  the  term  operational 
integration  framework  (OIF)  will  be  used. 

An  OIF  is  a  collection  of  executable  software.  The  OIF  is  a  skeletal  part  of  an  oper¬ 
ational  information  and  process  management  system.  The  OIF  is  a  set  of  services  and  data 
types  commonly  available  to  all  information  systems  based  on  the  OIF.  The  OIF  is  used  by 
human  users  and  software  (tools  and  agents)  to  structure  and  manage  information,  collec¬ 
tions  of  software  tools,  and  collections  of  external  process  in  an  integrated  fashion.  Tlie 
actual  information  being  managed  may  be  inserted  into  the  OIF,  but  is  not  part  of  the  actual 
framework.  The  framework  manages  both  information  and  metadata  about  the  information; 
that  is,  it  manages  the  information  model  that  the  user  organization  defines. 

Thus,  the  information  and  process  management  system  an  organization  uses  will  be 
made  up  of  an  OIF  filled  in  with  tools,  information  and  process  models,  information  bases, 
and  policies.  Two  systems  based  on  the  same  OIF  might  contain  different  kinds  of  tools  and 
information,  different  tools  and  information  of  tiie  same  kinds,  or  some  common  tools  and 
information.  Having  the  sanw  OIF,  the  organizations  owning  these  systems  would  have  an 
identical  notion  of  “kind”  and  so  would  be  able  to  exchange  information  of  the  same  kind. 
Communities  of  interest  would  have  a  base,  the  OIF,  in  which  to  implement  conventions  on 
information  representation,  service  interfaces,  and  kinds  of  policies  (e.g.,  configuration 
management),  and  would  know  that  these  conventions  were  enforceable  on  their  systems 
through  the  mechanisms  of  their  common  OIF. 

The  utility  for  integrated  information  infrastructures  of  systems  based  on  a  coimnon 
OIF  is  in  terms  of  interactions  within  the  uter  convnunity.  This  community  might  be  made 
up  of  organizations  within  a  company,  or  of  organizations  firom  several  companies  teaming 
to  design  and  build  a  product  In  either  case,  there  may  be  an  economic  payoff  in  a  standard 
OIF.  Currently  there  is  a  reasonable  level  of  understanding  of  the  OIF  concept  within  the 
community  of  potential  suppliers  of  OIF  products  and  of  tool  vendors  who  would  build  to 
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OIF-specified  interfaces.  There  is  reasonable  understanding  of  how  to  deal  with  legacy  sys¬ 
tems.  Rnally,  there  are  some  demonstration  products.  These  products  have  had  some  but 
not  overwhelming  market  penetration,  so  that  the  interface  specification  situation  has  not 
yet  gotten  out  of  control.  The  opportunity  exists  now  to  begin  the  process  of  OIF  standard¬ 
ization  in  earnest.  Continuing  demonstrations  of  various  approaches  will  be  needed  both  to 
settle  some  issues  and  to  demonstrate  utility  in  real  projects.  These  will  also  educate  the 
conununity  on  the  necessary  support  structures.  Nevertheless,  the  standardization  process, 
focused  on  an  OIF  approach  to  integrated  information  and  process  management,  is  now  fea¬ 
sible. 


2.2^.6  CASE  Frameworks 

The  software  engineering  community  is  developing  sophisticated  operating  frame¬ 
works  for  the  integration  of  software  engine^g.  For  CASE  environments,  “framework” 
is  generally  accepted  to  refer  to  a  set  of  common  services,  found  in  all  environments  and 
callable  by  an  od  hoc  tool  that  is  introduced  to  the  environment  The  National  Institute  of 
Science  and  Technology  Reference  Model^^  has  been  widely  accepted  throughout  the 
CASE  community.  The  NIST  Reference  Model  defines  several  categories  of  framework 
services:  object  management  task  management  communication,  user  interface,  tool  inte¬ 
gration,  security,  and  framework  administration  and  configuration. 

Most  frameworks  are  described  as  integrating  agents,  providing  data  integration, 
control  integration,  and  presentation  integration.  In  the  NIST  model,  the  data  and  control 
integration  are  categorized  as  object  management  services  and  presentation  integration  as 
a  user  interface  service.  Differing  strategies  for  objea  management  s^vices  are  a  partial 
reason  for  the  current  lack  of  uniformity  among  CASE  frameworks.  In  particular,  disagree¬ 
ment  on  an  objea-oriented  approach  to  information  management  continues  to  be  a  barrier 
to  widespread  agreement  on  framework  standards. 

2^2.7  Formal  Models 

Process  models  (see  Section  2.2. 1.8)  could  be  used  to  a  greater  extent  than  currently 
within  an  integrated  information  infrastructure.  Companies  visited  in  this  and  previous 
studies^  reported  a  desire  to  use  the  information  infrastructure  to  establish  work  proce¬ 
dures.  A  process  model  can  be  the  basic  data  structure  for  establishing  a  set  of  operational 

^  A  Reference  Model  for  Computer-Assisted  Software  Engineering  Environment  Frameworks.  National 
Institute  of  Standards  and  Technology  Working  Draft,  prepared  by  the  NIST  Integrated  Software  Engineer¬ 
ing  Environment  (ISEE)  Working  Group,  May  29, 1991. 
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procedures  guided  or  enforced  by  the  information  infrastructure.  The  infrastructure  itself 
would  have  standards  for  process  modeling  languages,  representations,  and,  perhaps,  meth¬ 
ods.  Version  control,  approvals,  and  configuration  management  could  all  be  automated 
based  on  such  models  and  their  use  within  the  infrastructure.  Currently,  some  companies 
have  thought  about  such  uses  and  a  few  vendors  are  marketing  products  that  allow  this  kind 
of  modeling  and  enforcement  Several  companies  voiced  concern  about  the  willingness  of 
workers,  particularly  engineers,  to  use  such  a  system. 

The  use  of  information  models  (see  Section  2.2. 1.8)  is  in  its  infancy.  Use  as  a  basic 
driver  is  beginning  to  appear.  If  all  information  managed  by  the  infrastructure  were  con¬ 
tained  in  a  machine-sensible  information  model,  there  would  be  a  greater  possibility  that 
the  meaning  of  the  information  could  be  conveyed  via  the  infrastructure  over  space  and 
time.  As  with  process  models,  this  assumes  that  standards  for  information  modeling  lan¬ 
guages,  representations,  services  and  methods  would  be  part  of  the  operational  framework 
for  the  infrastructure. 

The  capture  of  meaning  for  use  by  computers  is  both  an  available  technology  and  a 
research  issue.  Object-oriented  information  management,  organizing  information  into 
classes,  gives  an  ability  for  efficiently  inferring  attributes  of  an  item  of  data  from  its  class 
memberships.  No  companies  repotted  use  of  object-oriented  information  management  in 
this  study,  but  a  few  reported  use  of  object-oriented  programming  and  several  said  they 
were  monitoring  the  marketplace  to  determine  how  and  when  to  incorporate  this  technolo¬ 
gy  in  their  information  infrastructures. 

2,2,2.8  Security  and  Protection 

Several  of  die  companies  visited,  especially  but  not  exclusively  defense  contractors, 
mentioned  that  information  protection  and  security  were  important  issues  to  be  considered 
in  integrating  the  information  infrastructure. 

Integration  of  enterprise  information  is  taking  place  within  many  companies  along 
functional  lines  and  will  provide  ‘*large  islands”  of  processing  in  logically  centralized,  pos¬ 
sibly  widely  distributed  functional  centers.  For  many  companies,  the  next  step  is  integra¬ 
tion  across  frinction  lines,  beginning  with  key  functions  such  as  engineering  and 
manufacturing,  for  example.  Further  integration  to  include  suppliers  and  customers  is  envi- 

^  Linn,  J.  and  iWnncr,  R.  The  Department  of  Defense  Requirements  for  Engineering  irtformation  Systems 
(ElS)  Voiume  I:  Operational  Concepts  (NTIS  AD-A176  153)  and  Volume  //;  Requirements  (NTIS  AD- 
A176 154).  IDA  Pspet  P-1953.  Institute  for  Defense  Analyses,  Alexandria,  VA,  1986. 
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sioned  by  most  companies,  and  may  occur  before  cross-functional  integration.  These  inte¬ 
gration  steps  should  be  assessed  in  terms  of  security  risk  and  information  protection. 

Specific  risk  management  approaches  need  to  be  negotiated  and  defined  so  that  they  are 
suitable  to  the  environment  each  participant  brings  to  integration  planning. 

There  are  three  major  approaches  available  to  address  and  manage  risk  to  informa¬ 
tion  assets  or  to  assets  represented  by  information  in  automated  information  systems:  legal 
redress,  insurance,  and  the  incorporation  of  self-protection  through  security  measures.  All 
three  must  be  considered  in  assessing  the  trade-off  i.ni^oes  of  managing  both  unique  compa¬ 
ny-oriented  risks  and  general  inherent  risks  in  the  intCt^tion  of  enterprise  information.  In 
particular,  the  information  infrastructure  must  support  requirements  needed  for  legal 
redress  and  insurance  coverage,  and  must  provide  for  incorporating  appropriate  security 
measures.  These  approaches  are  discussed  in  irxire  detail  in  Appendix  A. 

13  CURRENT  STATE  OF  INTEGRATION 

13.1  A  SyntiMsittd  Higlh  Water  Mark 

The  integration  techimlogy  and  infrastructure  ekments  available  today,  in  1993, 
would  eruble  an  enterprise  to  develop  a  significant  integraoon  infrastructure.  However, 
integration  projects  are  constrained  by  cultural  ineitia.  financial  and  resource  limitations, 
and.  significantly,  risk  management  Thus.  Enterprise  Integration  projects  and  their  sup¬ 
porting  integration  infiastructures  tend  to  be  deployed  in  an  incremental  and  evolutionary 
manner.  Since  each  enterprise  chooses  its  integratioo  path  baaed  on  particular  business 
needs,  the  corporations  visited  in  this  study  each  piesenied  a  different  road  map  of  integra¬ 
tion  efforts  to  date  and  a  unique  snapshot  of  current  integratioo  infrastructure. 

The  following  scenario  presents  the  profile  of  a  hypothetical  int^raied  enterprise. 

This  profile  synthesizes  the  high-water  practioes  of  10  electronics  sector  corporations  vis¬ 
ited.^  All  the  integration  infrastructure  elements  and  integration  practices  described  in  the  I 

sceruuio  are  based  on  current  technology  and  have  been  validated  by  deployment  in  at  least 
one  company  visited.  Rgure  3  depicts  this  profile  of  an  integrated  electronict  enterprise. 

The  seven  boxes  in  Figure  3  represent  seven  key  actors  (functional  groups)  within 

an  enterprise.  The  main  horizontal  axis  corresponds  to  the  product  value  chain  of  suppliers-  ^ 

producer-consumers.  The  suppliers  provide  naierials  and  component  asaenMies  to  the 


”  Although  this  scenario  is  geared  to  the  electronics  industry,  the  best  pncUces  in  the  other  t«o  sectors  ve 
comparable.  ^ 
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Enteiprise  Integration  Activities; 

1 .  Transmit  purchase  orders  to  suppliers  electronically  using  EDI. 

2.  Deliver  drawings  and  schematics  to  suppliers  electronicaily. 

а.  Receive  product  orders  from  customers  electronically  using  EDI. 

4.  Schedule  deliveries  electronically  using  factory  capacity,  inventory,  and  work-in- 
progress  databases. 

5.  Cornpute  manufacturing  schedules  based  on  inventory,  capacity,  orders  and  deliv¬ 
ery  commitmenl  databases. 

б.  Apply  downstream  mles  in  design  process. 

7.  Approve  design  using  automated  design  approval  process. 

8.  Release  approved  design  to  manufacturing  via  an  electronic  vault. 

9.  Develop  parts  database,  parts  approved  t^  design  and  manufacturing. 

10.  Corrtpile  manufacturing  control  programs  for  PCBs  from  design  database. 

11.  Plan  and  optimize  manufacturing  control  programs  based  on  manufacturing 
schedules. 

12.  Print  manuals  and  documentation  on  demand,  custom  configured  to  product  op¬ 
tions. 

13.  Use  repair  hMory  database  feedback  to  improve  precision  of  service  diagnostics. 

14.  Use  repair  history  database  to  drive  ECO/MCO  for  reliability. 

15.  Respond  to  customers  request  repair  or  warranty  services. 

16.  Martaga  quaMy  programs  for  products,  using  design,  manufacturing  and  repair 

data. 

17.  Select  ‘‘corporate  standards.*  common  platforms,  tools,  and  other  technology  ele¬ 
ments  tor  use  on  a  corporate-wide  basis. 

18.  Have  senior  management  sponsor  successful  integration  projects. 

EDI  Eleceotic  Dli  ln>wcr>w<a< 

eca  PiMid  CtauK  Board 

ECOMCO  Cngmawirg  Clianga  Otdareilwu(ac»uiliifl  Chaneo  Ordor 

FlgHrel.  Functional  Groups  and  Processes  in  an  Integrated 
Electronics  Enterprise 


39 


I 


producer,  and  the  consumers  purchase  the  products  manufactured  by  the  producer.  The  pro¬ 
ducer  is  partitioned  into  five  actors  in  the  research,  development  and  production  process; 
managers  (Management),  design  engineers  (Design),  manufacturing  engineers  (Service), 
technical  writers  (Documentation),  and  field  and  factory  service  engineers.  A  line  between 
a  pair  of  groups  indicates  an  information  flow  in  support  of  integration  of  their  activities. 

Eighteen  integrating  actions  or  integrated  processes  are  also  shown,  each  represent¬ 
ed  by  a  circled  number.  Where  a  number  is  placed  next  to  a  box  representing  a  functional 
group,  the  corresponding  action  is  undertaken  by  that  group.  Where  a  number  is  placed  next 
to  an  information  flow  line,  the  action  is  performed  to  the  mutual  benefit  of  both  functional 
groups,  and  brings  about  some  of  the  information  flow  between  them.  A  brief  description 
of  each  activity  is  given  in  the  figure,  and  each  is  described  more  fully  in  the  following  para¬ 
graphs. 


2.3.1.1  Suppliers,  Producers,  and  Customers 

EDI  is  used  to  exchange  business  information,  including  purchase  orders,  invoices, 
and  advice  of  payment.  EDI  is  used  between  the  manufacturing  organization  and  its  sup¬ 
pliers,  and  between  customers  and  the  order  entry  organization  (activities  1  and  3).  EDI 
may  also  be  used  within  the  company,  between  divisions  that  have  a  supplier-consumer 
relationship.  The  EDI  transmissions  to  suppliers  may  be  issued  by  manufacturing’s  MRP 
(manufacturing  resource  planning]  nd  JIT  (Just  in  time)  systems. 

For  electronic  components,  a  purchase  order  must  have  an  attached  schematic  or 
technical  drawing.  Since  EDI  supports  only  the  transfer  of  business  forms,  drawings  must 
be  transmitted  via  a  supplementary  mechanism  (activity  2),  such  as  an  interchange  format 
for  the  CAD  system  in  which  the  drawing  was  created,  an  industry  standard  interchange 
format  (e.g.,  ICES,  a  neutral  document  exchange  format  (e.g..  Standard  Generalized  Mark¬ 
up  Language,  SGML),  or  a  proprietary  format  used  by  the  enterprise.  Frequently  a  supplier 
will  not  have  the  necessary  equipment  or  software  required  to  receive  drawings  and,  for 
smaller  suppliers,  the  purchaser  will  install  a  system  for  electronically  viewing  drawings  in 
the  supplier’s  facility.  For  security  reasons,  drawings  being  transferred  to  a  supplier  are 
either  downloaded  to  the  supplier’s  workstation  or  copied  to  an  isolated  workstation  in  the 
producer’s  plant  that  the  supplier  can  access  as  needed.  In  neither  case  is  the  outside  sup¬ 
plier  given  access  to  the  engineering  network  of  the  purchaser,  and  normally  the  purchaser 
is  not  given  access  to  the  network  of  the  supplier. 
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During  the  process  of  ordering  an  electronic  component,  particularly  components 
available  from  multiple  sources,  the  customer  will  seek  a  committed  price  quote  and  deliv¬ 
ery  schedule.  Data  involved  in  responding  include  finished  inventory  data,  work-in-process 
data,  and  manufacturing  capacity  data.  The  order  entry  system  accesses  these  data  from 
their  various  sources  within  the  company  in  responding  to  the  customer  (activity  4). 

23.1^  Design  and  Manufacturing 

A  flexible  CIM  facility  can,  in  principle,  manufacture  product  in  lot  sizes  of  one 
unit,  although  there  are  many  factors  that  favor  larger  manufacturing  runs.  Schedules  for 
each  manufacturing  line  are  computed  periodically,  the  frequency  depending  largely  on  lot 
sizes  and  setup  overhead.  (Shorter  setup  times  allow  more  frequent  scheduling.)  The  sched¬ 
uling  activity  (activity  S)  uses  order  and  delivery  comntitment  data,  finished  product,  work- 
in-progress  and  rruiterials  inventories,  and  manufacturing  capacity  information. 

Practicing  concurrent  engineering,  a  design  engineer  obtains  feedback  about  the 
suitability  of  the  emerging  design  for  downstream  processes,  in  order  to  e^iently  produce 
a  high  quality  design.  The  feedback  nay  be  provided  through  tools  run  by  the  design  engi¬ 
neer  (e.g..  an  expert  system)  or  it  may  be  provided  by  a  formal  or  informal  review.  For 
exan^le.  by  running  an  ASIC  design  through  a  design  rule  checker  using  appropriate 
design  rules  amid  parameters  (activity  6).  the  design  engineer  verifies  that  the  design  con¬ 
forms  to  die  ASIC  foundry’s  process  rules. 

When  a  design  engineer  completes  a  design  or  an  engineering  change  and  the 
design  is  ready  for  release,  it  goes  through  an  approval  process.  An  approval  form  giving 
the  name  and  version  of  the  design  is  routed  by  ckctrooic  mail  (activity  7)  for  the  required 
approvals,  which  may  include  the  designer,  a  quality  engineer,  the  project  lead,  and  one  or 
more  additional  managers.  A  password- verified  signature  is  entered  electionicaUy  for  each 
signer.  After  the  electronic  design  approval  has  been  compleied.  the  design  proceeds  in  the 
release  process  while  a  paper  ^iproval  form  is  circulated  in  parallel  for  formal  signature. 
The  paper  approval  form  is  required  because  electronic  signatures  have  not  been  estab¬ 
lished  as  legally  binding,  should  they  be  tequired  for  contractual  purposes. 

In  the  release  process  (activity  8).  the  approved  configuratioo  of  the  design  (the  cor- 
rea  version  of  the  design  and  the  correct  versions  of  the  components  used  in  the  design)  is 
checked  into  an  electronic  v»i1l  There  it  is  available  on  a  '’read-only**  basis  to  both  design 
engineering  for  reuse  in  future  design  activities  and  to  manufKturing  engineering  for 
developing  the  CIM  programs  used  in  the  manufacture  of  that  design. 
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When  designing,  an  engineer  specifies  some  purchased  components.  These  compo¬ 
nents  are  selected  from  the  shared  corporate  approved-parts  database.  Frequently  there  is  a 
choice  among  several  optional  parts  that  provide  the  required  functionality;  perhaps  a 
choice  among  options  with  identical  functionality,  but  from  different  suppliers.  In  this  case 
the  choice  may  be  based  on  manufacturing  issues.  (For  example,  choosing  a  chip  already 
in  use  on  the  manufacturing  line  avoids  additional  setup  time  to  custom  load  an  alternative 
chip  into  a  “pick-and-place”  machine.)  Manufacturability  information,  such  as  reliability, 
maintainability  and  usage,  is  collected  and  used  by  the  manufacturing  engineers,  and  the 
approved-parts  database  is  selected  (activity  9)  either  by  manufacturing  or  jointly  by  design 
and  manufacturing,  with  the  latter  having  veto  power. 

To  manufacture  a  PCB,  a  numerical  control  (NC)  program  for  control  of  the  fabri¬ 
cation.  drilling,  stuffing,  and  soldering  processes  must  be  developed.  The  approved  design, 
as  placed  in  the  electronic  vault,  is  the  specification  for  the  NC  program.  Manufacturing 
acquires  the  PCB  design  from  the  vault  and  compiles  the  NC  program  (activity  10). 

Some  optimization  of  an  NC  program  is  done  during  its  development  (i.e.,  in  activ¬ 
ity  10).  Much  of  the  optimality  of  the  CIM  operation  of  a  facility  depends  on  interactions 
among  the  various  NC  programs  for  the  parts  and  products  being  manufactured  in  that  facil¬ 
ity.  Therefore,  after  the  manufacturing  schedule  for  the  facility  is  established  for  the  day 
(week,  etc.),  further  QM  optimization  is  performed  (activity  11).  This  optimization  is 
based  on  the  CIM  NC  programs,  the  schedule  (from  activity  5),  and  the  materials  inventory 
and  outstanding  JIT  purchases  (activity  1). 

2J.U  Docuimnlatkm  and  Service 

Documentation  in  support  of  products  is  produced  by  many  group'  .s  all  collect¬ 
ed  into  a  documentation  database,  and  no  inventory  of  printed  nuuiuals  is  maintained  (other 
than  a  supply  of  blank  paper  for  the  printing  process).  When  a  unit  of  product  is  prepared 
for  shipping  to  the  customer,  a  manual  customized  to  describe  exactly  and  only  the  features 
in  that  product  unit  is  printed  on  demand  (activity  12)  just  in  time  for  inclusion  in  the  ship¬ 
ment 

As  a  side  benefit  service  documentation  reflecting  the  requirements  and  idiosyncra- 
cies  of  the  exact  product  configuration  of  a  unit  under  repair  can  be  read  electronically  by 
a  service  engineer.  This  allows  the  engineer  to  focus  on  the  failure  modes  and  repair  steps 
relevant  to  the  repair  task  at  hand.  The  same  diagnostic  results  for  two  different  configura¬ 
tions  of  a  product  night  be  correlaied  with  two  different  types  of  failure.  By  capturing  a 
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reliability  and  repair  history  database  (activity  13),  manufacturing  and  service  can  detect 
such  patterns  and  guide  the  service  engineer  to  a  precise  diagnosis  and  an  efiicient  repair 
process. 

Using  the  reliability  and  repair  history  database,  service  engineers  can  detect  (activ¬ 
ity  14)  a  recurring  pattern  of  poor  reliability  or  failures.  Service  can  describe  to  design  and 
manufacturing  groups  this  pattern  and  together  they  can  arrive  at  an  ECO  or  a  MCO  that 
addresses  the  problem. 

After  an  order  is  delivered  and  installed,  most  interaction  with  the  customer  is  per¬ 
formed  by  the  field  service  engineers.  By  establishing  electronic  mail  or  EDI  communica¬ 
tions  between  the  customer  and  the  service  engineer,  customer  requests  for  service  (activity 
15)  are  received  with  greater  timeliness  and  accuracy  than  manually,  and  electronic  com¬ 
munications  provide  the  opportunity  to  capture  this  input  for  the  reliability  database. 

2J.1.4  Management 

Quality  programs  such  as  continuous  product  improvement  (CPI),  “Six  Sigma,”  or 
total  quality  management  (TQM)  require  accurate  and  timely  data  on  all  products.  All  func¬ 
tions  in  the  enterprise  (e.g.,  design,  manufacturing,  service,  management)  must  collect 
accurate  data  appropriate  to  quality  measurement.  To  manage  the  quality  of  an  enterprise 
(activity  16)  requires  electronic  access  to  the  appropriate  data  from  these  disparate  sources, 
coupled  with  the  ability  to  integrate  the  data  into  a  model  that  enables  correlation  of  the 
overall  quality  of  a  product  with  the  data  elements  from  the  various  functions. 

Selection  of  common  tools  and  platforms  (activity  17)  has  two  positive  effects. 
First,  it  minimizes  the  cost  of  training  and  support  Second,  it  enables  the  tool  users  to  focus 
on  fewer  tools  and  to  spend  more  time  on  using  them  well;  this  indirectly  increases  the  qual¬ 
ity  of  the  products  produced  using  these  tools. 

Successful  integration  projects  are  characterized  by  bottom-up  opportunities  and 
top-down  sponsorship.  Opportunities  to  integrate  two  related  activities,  or  a  conunon  activ¬ 
ity  in  two  separate  but  related  organizations,  are  first  visible  to  the  two  groups  whose  activ¬ 
ities  would  benefit  from  their  integration.  Management,  particularly  a  manager  whose 
domain  of  control  spans  both  groups,  must  embrace  such  an  opportunity  and  provide 
enabling  ^nsorship  (activity  18)  to  the  individuals  who  will  execute  the  integration 
project 
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2.32  Summary  of  Current  Practice 

The  high  water  mark  scenario  presented  in  Section  2.3. 1  is  based  upon  the  best  prac¬ 
tices  of  organizations  visited  in  this  study.  In  actual  practice,  the  introduction  of  these  inte¬ 
gration  activities  is  more  widespread  than  might  be  implied  from  the  scenario.  Most 
organizations  currently  practice  several  of  these  integration  activities  to  some  degree.  Cur¬ 
rent  practice  as  surveyed  by  the  study  team  is  summarized  in  Figure  4. 

2.4  DOD  ROLE 

The  DoD  is  a  buyer,  creator,  and  maintainer  of  vast  amounts  of  product  and  process- 
related  information.  When  the  DoD  buys  a  weapons  system,  for  example,  it  is  involved  in 
the  definition  of  requirements  and  specifications,  the  receipt  of  technical  and  business  data, 
the  maintenance  of  technical  data  about  each  system  (as  built  and  as  specified),  and  other 
operational,  logistical,  and  business  information.  The  DoD  produces  spare  parts  and 
replacement  software  and,  as  such,  is  a  collection  of  manufacturing  enterprises.  Its  systems 
are  built  by  teams  of  contractors  and  subcontractors,  each  team  often  containing  thousands 
of  entities.  The  ability  of  the  DoD,  as  a  government  agency,  to  maintain  strategic  partner¬ 
ships  with  its  suppliers  is  very  limited  by  competition  regulations  and  law.  These  limits 
apply  to  DoD  prime  contractors  as  well. 

All  this  argues  for  the  development  and  use  of  a  dynamically  linkable  infc  rmadon 
infrastructure  on  which  DoD  can  layer  its  business  operations,  especially  those  involving 
outside  parties  such  as  contractors.  In  the  past,  the  DoD  has  paid  (directly  or  indirectly)  for 
the  creation  of  infrastructures  to  support  each  system  it  buys.  The  technology  and  under¬ 
standing  of  infrastructure  issues  is  now  at  the  point  that  DoD  can  consider  reducing  the 
inherent  inefficiency  of  repeated  infrastructure  creation.  Further,  the  continuing  cost  of 
maintaining  numerous  incompadbie  infirastructures,  one  for  each  kind  of  weapons  system, 
for  example,  is  increasingly  burdensome. 

Finally,  the  DoD  has  a  strong  military  interest  in  being  able  to  bring  new  technology 
to  field  operation  as  quickly  as  possible.  This  timing  interest  is  not  unique;  the  commercial 
electronics  industry  is  similarly  driven.  The  DoD,  though,  pushes  the  states  of  many  prod¬ 
uct  and  process  technologies  at  once  and  undertakes  unusual  technological  risk.  Military 
superiority  depends  on  success.  The  time-to-market  rationale  for  integration  and  informa¬ 
tion  infrastructures  used  in  commercial  industry  takes  on  this  additional  weight  in  the  DoD 
environment 
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7.  Manag«m»nt  sponsors  integration 


The  scope  of  DoD  Enterprise  Integration  requirennents  is  the  same  as  those  of  com¬ 
mercial  industry.  Therefore  it  makes  sense  for  the  DoD  to  team  with  industry  in  developing 
an  integration  infrastructure  meeting  those  needs. 

While  not  differing  in  scope.  DoD  requirements  do  differ  substantially  in  degree. 
Whereas  most  companies  visited  are  focused  on  intra-company  integration,  DoD  inherently 
operates  in  an  inter-organization  mode.  Some  DoD  product  ‘  '  'hr  F-22)  are  more  com¬ 
plex  and  have  mote  rigorous  perfomumce  requirements  .  .>1  commercial  products. 

Furthermtve.  the  DoD  acquisition  process  tends  to  incur  fresh-start  contract  q)ecific  ele¬ 
ments  of  integration  infrastructure  on  each  program.  The  DoD  accumulates  heterogeneous 
systems,  contract-unique  legacy  systems,  and  many  islands  of  integration  that  often  are  tru¬ 
ly  incompatible.  In  the  DoD  envirorunent.  a  homogeneous  systems  approach  is  generally 
not  legal. 

Thus,  DoD  has  a  stronger  interest  than  industry  in  general  in  solutions  such  as  stan¬ 
dard  middle  layers,  standard  operational  frameworks,  and  standard  information  exchange 
representations.  The  government  tends  to  prefer  a  vigorous  marketplace  in  open  informa¬ 
tion  system  tools  and  technologies  to  closed  or  proprietary  solutions.  The  DoD  has  recog¬ 
nized  in  several  programs  that  open-system  solutions  to  information  infrastructure  issues 
will  depend  on  operational  integration  frameworks.  DoD’s  interest  will  be  best  served  if 
framework  standards  span  the  domains  of  product  design,  production,  and  maintenaiKe. 

The  DoD  has  a  qiecial  interest  in  the  evolvability  of  the  infrastructure  for  several 
reasons:  it  has  tens  of  thousands  of  l^acy  systems  to  absorb  over  time,  it  has  very  long- 
lived  products  and  associated  information,  and  it  has  products  that  evolve.  Inter-organiza¬ 
tional  factors  introduce  an  additional  element  of  change,  which  may  be  a  threat  to  evolv¬ 
ability.  Having  a  slowly  evolving  framework  in  which  to  house  relatively  mote  quickly 
evolving  information  and  rimdels  and  residing  on  very  rapidly  evolving  platforms  is  a 
requirement  for  rationalizing  DoD  information  numagement 

Sofrware  makes  up  a  very  large  and  growing  fraction  of  the  DoD  acquisition  bud¬ 
get  The  DoD  theref(»e  has  an  unusually  strong  interest  in  the  engineering  process  that  sur¬ 
rounds  the  software  it  buys,  uses,  and  maintains.  The  cost  of  buying  and  operating  a  unique 
software  engineering  envirorunent  for  every  piece  of  mission-critical  software  has  gotten 
very  large.  The  DoD  seeks  a  solution  through  framework,  language,  and  interface  stan¬ 
dards.  Furthermore,  the  DoD  is  beginning  to  recognize  that  it  is  possible  for  a  framework 
to  span  more  than  one  domain,  for  exan^le  both  software  and  computer  hardware  devel¬ 
opment  The  DoD  work  on  CASE  frameworks  may  prove  to  be  useful  in  this  larger  setting. 
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The  security  issue  for  DoD  is  older  but  not  technically  very  different  from  the  issues 
relating  to  trade  secrets  and  con^titive  information  faced  by  industry.  Again,  the  differ¬ 
ences  are  largely  a  matter  of  scale.  Compartmentalized  and  extremely  sensitive  information 
must  be  managed.  Development  of  classihed  systems  using  a  geographically  distributed 
infrastructure,  as  was  done  in  the  B-2  program,  for  example,  is  very  difficult  at  the  current 
sute  of  the  art. 

The  DoD’s  needs  for  Enterprise  integration  can  best  be  met  by  working  with  com¬ 
mercial  industry  to  develop  the  required  information  infrastructure.  While  the  government 
will  support  projects  and  activities  that  develop  and  standardize  this  infrastructure,  the  DoD 
needs  to  ensure  that  adequate  attention  is  paid  to  its  specific  needs  including,  for  example, 
legacy  systems,  evolvability  of  operational  integration  frameworks,  and  management  of 
security  information. 

ENGINEERING  OF  INTEGRATED  INFORMATION  SYSTEMS 

Section  2.2.2.  Technical  Factors,  contains  numerous  examples  of  difficult  trade-offs 
that  must  be  made  in  designing  integrated  information  systems  and  mating  them  with  con¬ 
tinuously  evolving  organizations  and  processes.  The  company  visits  made  during  this  study 
show  that  progress  is  being  made  in  implementing  increasingly  complex  integrated  sys¬ 
tems.  Yet  the  engineering  of  these  systems  is  based  more  on  intuition  and  experiential  rules- 
of-thumb  than  on  a  sound  science  or  analytic  technology.  As  pilot  and  demonstration  sys¬ 
tems  are  implemented  and  new  approaches  explored,  community  experience  will  increase. 
Unfortunately,  very  little  of  this  learning  is  being  disseminated  at  present  There  are  active 
research  areas  within  information  infrastructures,  but  transfer  of  results  to  the  industrial 
community  appears  irudequate. 

As  exanqrles  of  issues  that  would  benefit  from  concerted  attention,  and  where  ben¬ 
efits  seem  achievable,  consider  the  following. 

•  Representing  the  semantics  of  mechanical  design  entities.  The  electronic  CAD 
world  has  dealt  with  the  functional  behavior  of  design  elements  for  a  long  time, 
but  mechanical  CAD  (MCAD)  is  still  practiced  at  the  geometry  level.  “Feature- 
based  design”  is  the  term  most  commonly  associated  with  bringing  mechanical 
CAD  to  a  level  where  the  purpose  of  each  item  is  known  to  the  CAD  system 
and,  therefore,  can  be  kept  as  part  of  the  design  history  and  rationale.  Bringing 
the  MCAD  world  to  the  semantic  level  would  allow  information  modeling  for 
electromechanical  systems  to  admit  more  consistent  solutions  than  exist  today. 


47 


•  Representation  of  management  policies  for  use  in  process-model-driven  infor¬ 
mation  systems.  Policies  (expressed  as  rules)  could  be  represented  as  entities  in 
process  and  information  models.  A  mechanism  for  executing  policies  could 
then  be  applied  by  the  information  infrastructure  to  such  activities  as  version 
control,  configuration  management,  and  methodology  enforcement.  Given  met¬ 
rics  to  measure  the  effectiveness  and  efficiency  of  these  activities,  enterprise 
simulations  would  allow  testing  the  effects  of  policies  prior  to  deployment. 

•  Evolvability  (implementation  for  change)  of  infirastructure  architecture  and 
components.  Mechanisms  for  evolvability  are  beginning  to  emerge  in  products, 
and  leading  users  are  beginning  to  plan  for  evolvable  systems.  Among  the  many 
open  questions  in  planning  for  evolvability  are,  for  example,  how  detailed 
should  the  information  model  be?  At  what  levels  of  granularity  should  seman¬ 
tics  be  formal  and  machine  sensible,  as  opposed  to  informal  (and,  therefore,  not 
interpretable  by  machine)?  What  are  the  maintenance  requirements  for  an 
object  base?  How  can  an  enterprise  control  the  growth  and  proliferation  of 
information  classes  within  its  infi^tructure? 

•  Open  system  vs.  closed  system  trade-o^s.  In  Section  2.2.23,  there  is  an  argu¬ 
ment  that  the  performance  shortconungs  of  open  systems  may  be  eliminated 
over  time  by  the  response  of  the  marketplace.  Among  the  many  open  questions 
are,  for  example,  what  are  the  trade-oifs  involved?  What  methods  should  be 
used  for  measuring  openness  and  integration,  and  their  effects?  How  does  infor¬ 
mation  system  performance  relate  to  the  performance  of  suri  ounding  processes? 
The  tendency  toward  local  optimization  is  not  just  based  on  cultural  biases  and 
reward  structures,  but  in  part  reflects  the  contention  that  openness  and  integra¬ 
tion  together  yield  low  performance.  Among  the  measures  to  be  developed  are 
process  measures  to  apply  to  human  processes.  These  involve  social  as  well  as 
technical  considerations.  For  example,  does  high-level-management  visibility 
into  measurable  low-level  processes  help  or  hinder  process  and  enterprise  effi¬ 
ciency? 

In  summary,  there  are  many  opportunities  to  develop  a  greater  scientific  and  engi¬ 
neering  understanding  on  which  to  base  integration  decisions.  Some  issues  are  information 
system  specific;  others  have  to  do  with  the  measurement  and  management  of  the  enterprise 
in  general.  All  would  benefit  from  a  greater  basis  of  understanding. 
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2.6  RELATIONSHIP  TO  OTHER  CONCEPTS 

Several  industry  representatives  interviewed  in  this  study  felt  that  the  relationship 
of  enterprise  integration  and  information  infrastructure  to  certain  other  topics  should  be  dis¬ 
cussed.  In  particular,  concurrent  engineering.  CIM,  CAD  integration,  and  flexible  manufac¬ 
turing  were  most  often  nwntioned. 

Concurrent  engineering  seeks  to  integrate  the  engineering  of  products  and  their 
related  processes.  It  also  seeks  to  integrate  the  different  engineering  domains  within  prod¬ 
uct  design.  As  such  it  is  a  subset  of  enterprise  integration  because  it  integrates  the  design 
aspects  of  the  whole  product  life  cycle  from  recognition  of  need  through  design,  produc¬ 
tion,  operation,  and  maintenance  to  disposal.  In  large  projects  concurrent  engineering 
necessitates  inter-company  integration  of  activities  and  information  flows.  Thus,  concur¬ 
rent  engineering  requires  the  information  infrastructure  and  demands  that  the  infrastructure 
be  controllable  an  J  evolvable.  Concurrent  engineering  expects  the  infrastructure  to  enable 
CAD  integration  because  of  its  requirement  to  integrate  engineering  domains.  Concurrent 
engineering  receives  constraints  from  flexible  manufacturing  and  the  degree  of  flexibility 
should  affect  tht  resulting  product  designs.  Concurrent  engineering  outputs  product  and 
process  designs  1 1  CIM  via  the  information  infrastructure. 

CIM  is  boti  an  integrated  activity  and  an  integrated  information  system.  It  is  an 
integrated  activity  in  that  all  manufacturing  activities  are  considered  as  a  system.  It  is  an 
integrated  information  .^stem  bvxause  computers  and  their  related  communications  sys¬ 
tems  are  used  as  the  mechuiisms  for  creating  a  unifred  system  out  of  the  many  manufactur¬ 
ing  entities.  As  such  it  Is  a  subset  of  b(Hh  enterprise  integration  arxl  information 
infrastructure.  It  can  receive  information  from  integrated  CAD  via  the  information  infra¬ 
structure.  It  is  of  particular  utility  beca>ise  it  can  dyruunically  define  arul  organize  the  activ¬ 
ities  of  flexible  manufacturing  entities. 

CAD  integration  is  to  information  infirastructure  as  concurrent  engineering  is  to 
enterprise  integration.  That  is,  CAD  integration  is  a  subset  of  integrated  information  irtfra- 
structurc  as  particularly  applied  to  CAD  and  CAE.  It  receives  inputs  from  the  requirements 
and  specification  process  and  produces  ouqnits  to  CIM  both  via  the  information  infirastruc¬ 
ture.  It  supports  concurrent  engineering  by  allowing  broad  information  sharing  among 
engineering  activities. 

Hexible  manufacturing  is  the  use  of  manufacturing  equipment  '  -oducc  more 
than  one  product  in  an  economic  mix.  It  is  used  within  CIM  to  bring  abou  »e  (but,  per- 
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haps,  not  all)  of  the  production  activities  on  a  manufacturing  line.  It  takes  advantage  of  the 
information  infrastructure  as  part  of  CIM.  It  places  its  own  kind  of  manufacturing  con¬ 
straints  on  the  concurrent  engineering  activities. 
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3.  INDUSTRIAL  ENTERPRISE  INTEGRATION  VISION--2001 
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3.1  INTRODUCTION 

This  section  presents  a  vision,  one  possible  scenario,  of  future  industrial  enterprise 
integration  suggested  by  the  findings  of  this  study.  The  vision  is  meant  to  describe  a  possi¬ 
ble,  desirable  state  of  enterprise  integration  in  the  future.  It  is  not  a  forecast,  but  rather  a 
goal  state.  The  technologies  required  to  achieve  this  state  are  available  now,  thus  the  goal 
is  feasible.  However,  it  could  still  pose  a  challenge  to  industry  in  reaching  it  by  the  stated 
date,  or  ever.  The  vision  is  presented  from  two  perspectives:  first,  in  terms  of  the  efrect  of 
information  infrastructures  on  enterprise  integration  as  they  have  developed  by  the  year 
2001,  and  second,  in  terms  of  the  technological  developments  that  have  permitted  that 
effect  The  purpose  of  the  vision  is  to  provide  focus  for  plarming  and  implementing  these 
infrastructures. 

The  vision  reported  here  has  been  developed  by  synthesizing  appropriate  ideas  from 
a  variety  of  planning  exercises,  books,  and  rqports.^  In  addition,  we  asked  a  panel  of  indi¬ 
viduals  with  experience  in  relevant  areas  for  comments.  They  recommended  eliminating 
specific  quantitative  predictions  in  favor  of  descriptive  terms.  As  the  process  of  refining  the 
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vision  moves  forward,  an  early  step  would  be  to  consider  how  much  of  it  can  be  realized 
by  1996,  and  in  that  context,  if  specific  figures  can  then  be  given. 

3.2  THE  EFFECT  OF  INFORMATION  INFRASTRUCTURES  ON  ENTER¬ 
PRISE  INTEGRATION— 2001 

By  2001  many  changes  have  influenced  the  state  of  enterprise  integration.  The  glo¬ 
bal  economy  is  more  advanced,  with  greater  requirements  for  rapid,  timely  exchange  of 
information  between  distant  locations.  The  impact  of  multi-national  (or  global)  companies 
is  better  recognized,  and  significant  capital  investments  have  been  made  in  the  information 
infrastructures  required  to  support  an  integrated  enterprise. 

There  are  parallel  changes  in  business  cultures.  Success  stories  of  enterprise  inte¬ 
gration  have  helped  to  remove  barriers  that  impede  sharing  control  of  information.  Compa¬ 
nies  more  readily  assimilate  integrated  systems  into  their  way  of  doing  business. 

Government  agencies,  facing  increased  pressures  to  achieve  significant  cost  reduc¬ 
tions  without  sacrificing  effectiveness,  have  also  responded  to  these  technological  advances 
and  industrial  sector  successes.  DoD,  in  particular,  has  demonstrated  a  leadership  role  in 
implementing  key  aspects  of  enterprise  integration. 

3.2.1  State  of  the  Infrastructure 

By  coordinated  efforts,  a  national  high-capacity  information  network,  the  backbone 
of  a  national  Enterprise  Integration  Infrastructure,  has  been  put  in  place  in  the  United  States 
and  is  considered  essential  to  U.S.  competitiveness.  Similar  efforts  have  developed  varying 
infrastructures  in  the  European  Community  and  in  other  parts  of  the  world,  with  some  com¬ 
mon  features,  shared  standards,  and  abilities  to  share  certain  information.  In  the  United 
States,  some  economy-wide  data  is  in  standard  form  and  shared  through  the  Infrastructure. 
Some  industries  have  adopted  standardized  product  data  representations  using  forms 
beyond  merely  text,  and  are  routinely  sharing  data. 

Enterprise  Integration  has  been  stimulated  by  the  following: 

•  The  need  to  increase  productivity  and  decrease  time-to-market  or  time-to-deliv- 
ery  in  manufacturing. 

•  Horizontal  and  vertical  partnering  relationships. 

•  Intra-company  integration  to  promote  competitiveness. 
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It  has  also  allowed  improved  management  practices  through  information  availability  and 
better  quality  control  through  awareness  and  prevention  of  errors. 

The  infrastructure  has  enabled  widespread  and  growing  enterprise  integration  by 
allowing  both  large  and  snudl  firms  to  participate  in  integration  more  easily,  reducing  the 
cost  of  the  necessary  transitions.  It  has  opened  opportunities  for  new  products  and  services, 
and  has  provided  new  ways  to  compete  for  those  innovators  who  have  adapted  to  it. 

322  Evolving  the  Infrastructure 

National  mechanisms  are  in  place  to  facilitate  cooperation  among  standards  bodies 
and  to  assure  the  orderly  evolution  of  the  Enterprise  Integration  Infrastructure  for  the 
future.  Relevant  standards  developed  by  established  professional  and  standards  organiza¬ 
tions  provide  for  necessary  evolution,  and  stress  flexibility  for  innovation  and  interchange- 
ability  through  voluntary  adherence.  The  value  to  organizations  and  vendors  of  the 
Infrastructure  is  so  widely  recognized  that  reliance  on  voluntary  adherence  is  successful. 

The  Infrastructure  is  based  on  an  Operational  Information  Framework^^  that  sup¬ 
ports  evolution  of  information  types  and  allows  continual  improvement  of  die  underlying 
platforms  and  communication  technologies.  The  national  information  highway  provides  an 
example  of  managing  the  evolution  of  Infrastructure  components. 

Communication  interfaces  and  filters  exist  among  enterprise  integration  infrastruc¬ 
tures  world  wide,  and  cooperative  endeavors  are  underway  to  move  to  a  common  frame¬ 
work  over  the  next  two  decades.  In  some  information-intensive  industries  (e.g.,  financial) 
there  is  substantial  progress  towards  (what  appears  to  the  user  as)  a  single  global  informa¬ 
tion  infrastructure.  Many  large  world-wide  manufacturing  enterprises  are  developing  their 
own  global  infrastructures  for  internal  use,  and  are  providing  valuable  input  to  the  standards 
development  process. 

3,23  FacilluUng  the  IVanaiUon  to  Enterprise  Integration 

The  inqxntance  of  participation  in  enterprise  integration  to  small  business  has  been 
widely  recognized.  Experience  with  the  transition  to  enterprise  integration  is  being  gath¬ 
ered,  studied,  and  made  available.  Mechanisms  have  been  developed  and  are  constantly 
being  refined  to  enable  organizations  not  yet  operating  in  an  integrated  fashion  to  move  in 
that  direction.  Federal  and  state  agencies  supporting  small  business  development  now 
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advocate  and  fund  integration  activities.  Academic  study  of  the  mechanisms  and  effects  of 
integration  continues  to  grow. 

3.2.4  Effect  on  Competition 

Existence  of  the  national  Enterprise  Integration  Infrastructure  has  had  a  mixed 
effect  on  competition. 

•  On  one  hand,  it  has  facilitated  joint  ventures  and  other  horizontal  and  vertical 
integration  relationships,  supporting  a  continuing  trend  toward  fewer,  more 
closely  coupled  suppliers. 

•  On  the  other  hand,  it  has  enabled  relatively  inexpensive  routes  to  the  market¬ 
place.  Ideas  and  innovations  have  assumed  more  value,  and  location  and  own¬ 
ership  of  capital,  the  means  of  production,  and  information  are  no  longer  as 
formidable  obstacles. 

Within  this  context,  large  organizations  are  forced  to  compete  nationally  and  internation¬ 
ally,  and  they,  in  turn,  require  their  component  divisions  and  their  suppliers  to  compete. 

The  trend  toward  outsourcing  for  goods  and  services  is  supported  by  the  Infrastruc¬ 
ture,  helping  to  create  an  economy  in  which  large  organizations  reduce  their  employment 
and  many  small  ones  arise  to  provide  services  formerly  carried  out  within  the  larger  one. 
TliC  role  of  firms  as  assemblers  of  outside  components  has  expanded  to  include  assembly 
of  outside  services  also. 

3.2.5  Customizing  Products 

Customizing  products  is  possible  at  much  lower  dollar  and  time  cost  than  was  pre¬ 
viously  the  case.  This  is  highly  beneficial  in  military  markets,  where  the  need  for  special¬ 
ized  equipment  and  supplies  had  led  to  very  high  costs,  and  in  space  and  research  settings, 
where  similar  custom  or  small  lot  needs  are  found.  Customizing  products  is  also  providing 
more  options  for  consumers,  aiding  in  sales  of  U.S.  products. 

Within  the  military  logistics  stmeture,  the  infusion  of  CIM  technology  has  led  to 
reduced  cost  and  lead  times  in  the  procurement  of  small  quantities  of  high  quality  parts  by 
manufacturing  on  demand,  thus  reducing  the  costs  of  warehousing  and  overproduction. 

3.2.6  Savings  in  Time  and  Cost 

In  manufacturing  industries,  time  to  prototype  new  product  versions  has  been  reg¬ 
ularly  cut  to  a  fraction  of  what  it  had  been  a  decade  earlier.  This  has  led  to  new  product 
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development  times  which  are  correspondingly  lower.  Similar  reductions  have  been  realized 
in  development-to-deployment  time. 

The  transition  time  for  innovative  ideas  to  development  has  become  half  or  less  of 
what  was  traditional  in  the  twentieth  century.  These  innovative  ideas  in  many  cases  come 
into  an  organization  from  the  outside,  through  teaming  relationships  with  small  businesses. 

Real  costs  for  engineering  design  have  been  cut  substantially.  Enormous  gains  in 
engineering  productivity  has  been  noted  by  various  manufacturers  and  design  organiza¬ 
tions. 

Overall  manufacturing  personnel  costs  have  been  cut  substantially  due  to  automa¬ 
tion  and  productivity  gains  within  activities  that  had  previously  been  labor  intensive.  There 
have  been  drastic  reductions  in  manufacturing  lead  time  and  in  work-in-progress,  and  large 
gains  in  overall  production. 

Capital  equipment  is  replaced  less  frequently  because  of  the  flexibility  and  evolv- 
ability  provided  by  integration.  This  has  led  to  gains  of  hundreds  of  percentage  points  in 
operational  productivity.  These  gains  have  been  achieved  simultaneously  with  large 
improvements  in  production  quality,  with  little  need  to  stop  production  to  deal  with  defects. 

32  J  Managing  the  Flow  of  Information 

Sophisticated  standards  for  product  data  exchange  are  widely  used  in  most  major 
manufacturing  areas.  These  standards  extend  beyond  American  enterprises  to  others 
around  the  world. 

Product  data  information  is  routinely  used  with  generic  tools  in  automated  process 
planning,  generative  numerical  control  programming,  automated  inspection,  and  computer- 
aided  inventory  control. 

The  DoD  CALS  program  has  resulted  in  the  widespread  use  of  computerized  tech¬ 
nical  information  on  weapons  systems  and  has  moved  beyond  weapons  systems  into  other 
DoD  systems.  It  is  being  used  by  other  government  agencies  as  well.  It  has  reduced  costs 
of  documentation  while  adding  flexibility  for  both  the  government  and  business. 

Within  the  civilian  sector,  the  results  of  CALS  and  related  activities  have  had  valu¬ 
able  ramifications  for  a  variety  of  organizations,  leading  to  systems  that  rely  primarily  on 
paperless  data.  The  result  has  been  cost  savings  and  flexibility. 


New  forms  of  accounting  have  been  developed  and  continue  to  develop  to  account 
for  the  value  and  value  added  of  informational  entities  and  operations.  Activity-based 
accounting  has  had  a  major  influence  in  this  development.  Tools  to  use  these  new  methods 
of  accounting,  and  related  tools  for  financial  control,  have  been  incorporated  in  the  Infra¬ 
structure  as  they  are  developed. 

As  part  of  the  information  network  that  Drucker  envisioned  as  constituting  the  “fac¬ 
tory  of  the  future,”  and  that  has  in  fact  become  the  backbone  of  the  modem  business,  the 
Enterprise  Integration  lirfrastructure  has  acconrunodated  traditional  data  processing  and 
information  systems.  The  Infrastructure  has  allowed  different  trade-offs  in  data  access  and 
distribution  within  the  organization.  It  has  made  possible  the  notion  of  integrated  informa¬ 
tion  management  for  the  entire  enterprise,  not  just  separate  information  managements  for 
the  components  organizations.  It  has  provided  additional  services  and  filters  that  have 
allowed  further  automation  of  traditional  data  processing.  Information  management  princi¬ 
ples  continue  to  evolve  with  experience,  and  the  Infrastructure's  continuing  evolution  takes 
full  account  of  them. 

3.2Ji  Management  in  Integrated  Enterprises 

Management  methods  emphasizing  enterprise  integration  are  considered  important 
or  essential  over  a  broad  spectrum  of  companies,  both  inside  and  outside  of  manufacturing. 
Professional  practices  routinely  employ  the  ntethods  of  enterprise  integration  in  their  inter¬ 
actions  with  coiporations  utilizing  the  Infrastructure. 

Custom-tailoring  of  reports  and  other  information  products  is  now  conunonplace  in 
integrated  enterprises,  enabled  by  the  use  of  integrated  data  representations.  Data-access 
tools,  based  on  dual-use  technology  developed  for  military  command  and  control,  are  being 
introduced  into  commercial  use.  These  tools  enable  executives  to  develop  data  “probes” 
that  fit  their  own  styles  of  taking  the  pulse  of  the  organization,  pulling  information  when 
needed  rather  than  waiting  for  scheduled  reports.  Such  tools  are  made  possible  by  and 
accomiTKxiated  within  the  Infrastructure. 

It  is  becoming  widely  recognized  that  every  manager  in  a  manufacturing  enterprise 
should  learn  and  practice  a  discipline  that  integrates  engineering,  business  economics,  man¬ 
agement  of  people,  and  management  of  information  into  the  manufacturing  process.  Such 
a  discipline  is  being  systematized  and  beginning  to  be  taught  in  engineering  and  business 
schools.  Just  as  all  managers  learned  to  live  with  and  use  computers,  so  all  managers  are 
beginning  to  learn  to  live  with  and  use  integrated  systems  concepts  and  techniques.  Tools 


56 


to  aid  these  managers  are  steadily  improving  as  the  demand  grows.  Management  evaluation 
and  compensation  practices  are  beginning  to  reflect  the  value  of  this  knowledge.  A  rudi¬ 
mentary  general  understanding  of  the  enterprise  integration  infrastructure  is  now  consid¬ 
ered  a  basic  part  of  good  management. 

3J.9  Personnel  in  Integrated  Enterprises 

People  in  integrated  organizations  typically  are  utilized  more  effectively  and  are 
more  productive.  They  tend  to  be  comfortable  with  the  information  systems  that  are  essen¬ 
tial  to  their  jobs,  feeling  that  they  have  a  better  idea  of  the  “big  picture”  in  their  organization 
and  that  they  are  able  to  communicate  and  contribute  better  within  the  new  environment. 
The  systems  themselves  are  increasingly  engineered  to  provide  human  interfaces  that 
acconunodate  to  the  work  practices  of  individual  users. 

Tools  accommodated  by  the  Infrastructure  facilitate  training  of  new  personnel  and 
flexibility  of  existing  personnel  in  moving  among  jobs.  The  tools  capture  standard  practice 
aspects  of  the  “corporate  culture,”  enabling  it  to  be  reinforced  widely. 

3^.10  The  Effect  on  the  DoD 

DoD  is  ideally  suited  to  benefit  from  enterprise  integration.  It  is  an  enterprise  with 
geographically  dispersed  organizations  and  suppliers,  characterized  by  changing  programs 
and  combinations  of  work  teams,  and  the  need  to  respond  to  developing  technology.  As 
such,  DoD  has  always  been  involved  in  enterprise  integration  and  is  experiencing  many  of 
the  quality  improvements  and  cost  reductions  cited  above. 

Several  leadership  efforts  undertaken  over  the  last  decade  have  contributed  signifi¬ 
cantly  to  the  benefits  DoD  is  now  realizing.  These  activities  have  included  (1)  systematic 
efforts  to  identify  and  disseminate  learnings  firom  early  DoD-sponsored  integration  efforts, 
such  as  the  B-2  development;  (2)  specific  endeavors  to  develop  needed  technologies  and 
standard  practices  for  such  key  (to  DoD)  issues  as  dealing  with  legacy  systems,  smoothly 
integrating  heterogeneous  systems,  and  providing  secure  electronic  signatures  and  auto¬ 
mated  sign-offs;  and  (3)  working  with  suppliers  to  identify  and,  where  possible,  modify  the 
policies,  rules,  regulations,  directives,  procedures,  and  practices  that  are  seen  as  barriers  or 
inhibitors  to  industry's  use  of  Enterprise  Integration  Infrastructure  within  DoD  programs. 
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3.3  TECHNOLOGICAL  DEVELOPMENTS  IN  INFORMATION  INFRA¬ 
STRUCTURES 

Improvements  in  the  Enterprise  Integration  Infrastructure  in  2(X)1  have  been  made 
possible  by  interacting  changes  in  the  vision  of  the  future  and  organizational  structures,  and 
improvements  in  technological  capabilities.  The  follow  sections  discuss  these  technologi¬ 
cal  developments  contributing  to  integrated  information  infrastructures. 

Continued,  predictable  advances  in  the  cost  and  capability  of  semiconductors  and 
electronic  components  over  the  past  decade  have  resulted  in  highly  cost-effective  hardware 
systems. 

Continued  development  and  more  widespread  adoption  of  object-oriented  software 
technology  have  helped  to  expand  the  size  and  range  of  possible  applications,  particularly 
in  dealing  with  data  structured  in  diverse  ways,  such  as  formatted  documents,  sound,  graph¬ 
ics  with  identifiable  parts,  textured  surfaces,  movement  in  three-dimensional  space,  and  so 
forth. 

Selective  use  of  software  and  hardware  technologies  incorporating  learning,  such 
as  rule-based  expertise,  fuzzy  logic,  and  neural  networks,  has  extended  information  pro¬ 
cessing  capabilities  in  some  applications  where  precise  algorithms  are  not  available  or 
where  system  self-modification  based  on  experience  is  more  cost  effective  than  human 
analysis  and  programming. 

The  availability  of  high-speed,  high-capacity  data  transfer,  together  with  the  capa¬ 
bility  to  provide  access  to  massive  data  stores,  has  led  to  greater  awareness  of  the  impor¬ 
tance  of  standards  for  information  representation  and  for  software  interfaces.  Software 
innovators  throughout  the  network  see  value  in  being  able  to  “hook  up”  with  the  data  and 
software  components  of  other  innovators,  often  developed  and  housed  on  quite  different 
platforms.  What  was  formerly  an  issue  within  a  few  specialized  communities,  such  as  the 
electronic  CAD  community,  is  becoming  a  generally  recognized  need. 

3J.I  Data  Accessibility  and  Usability 

CALS  for  the  DoD  and  similar  smaller  initiatives  in  a  few  industries  have  made  data 
widely  accessible,  and  many  organizations  have  reached  their  limits  in  the  ability  to  inter¬ 
pret  available  data.  The  distinction  between  accessible  data  and  usable  information  is  more 
widely  recognized,  and  efforts  have  begun  to  increase  the  usability  of  accessible  data.  NIST 
and  the  DoD  are  sponsoring  activities  to  extend  IRDS  (Information  Resource  Dictionary 
System)  standards  so  as  to  capture  semantics  about  how  to  use  data,  as  well  as  developing 
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more  procedurally  oriented  standards  such  as  those  pioneered  by  the  Object  Management 
Group  (OMG),  the  CAD  Framework  Initiative,  and  PDFS  in  their  API  (Application  Pro¬ 
gram  Interface)  work. 

3.3 J  System  Hardware 

Significant  advances  in  technology  have  occurred  during  the  last  decade,  enabling 
better  support  of  integration  infrastructures.  All  of  the  following  are  improved  by  a  factor 
of  8  in  the  last  10  years:  processor  speed  and  cost,  memory,  storage  capacity  and  cost,  and 
network  capacity  and  reliability.  Workstations  are  multiprocessor  systems  with  multiple 
multimedia  displays. 

3.33  Database  Technology 

Database  technology  has  evolved  to  enhance  information  usability  and  to  provide 
adaptive  interfaces.  Relational  and  object-oriented  data  models  are  understood  as  two 
views  of  the  same  data  services.  Tables  or  spreadsheets  are  a  conventional  mechanism  for 
accessing  and  manipulating  enterprise  data.  The  semantics  associated  with  data  objects  are 
supported  by  the  cell  objects  in  the  tables  or  spreadsheets.  Hybrid  databases  have  developed 
as  a  mechanism  to  evolve  “legacy”  databases,  such  as  those  in  older  hierarchical  or  rela¬ 
tional  database  management  systems,  into  the  newer  database  servers. 

33.4  Networks,  Archives,  and  Development  Information 

Although  network  capacities  and  data  storage  capacities  have  increased  dramatical¬ 
ly,  the  con^lexity  of  the  enterprises  that  they  support  has  increased  their  utilization  com- 
mensurately.  Networks  continue  to  have  a  backbone  and  hub  architecture,  with  local 
networks  attached  at  the  hubs.  These  hubs  are  the  loci  of  conunon  and  application  frame¬ 
work  services.  Mainframe  computers  have  evolved  to  data  servers  functioning  as  the  net¬ 
work  hubs.  They  provide  electronic  vault  and  archive  facilities  for  data  that  will  have 
historical  significance,  such  as  released  versions  of  engineering  data,  documentation,  and 
safety  and  maintenance  data  as  required  by  law.  Data  for  work  in  progress  is  stored  in  local, 
project-team  (workspace)  databases  at  workstations  or  local  hubs  that  serve  development 
teams.  These  network  hubs  also  provide  enterprise-wide  peer-to-peer  communication  ser¬ 
vices  (e.g.,  electronic  mail). 

333  Legacy  Systems 

The  cost  of  acquiring  data  is  generally  recognized  as  greater  than  the  cost  of  storing 
the  data.  Strategies  for  hybrid  database  systems  allow  use  of  “legacy”  systems  in  a  static 


mode,  coexisting  with  successor  systems  that  are  serving  updates  and  other  dynamic 
requirements.  Hybrid  combinations  of  database  systems  enable  an  evolutionary  migration 
of  already  acquired  data  into  newer  integrated  systems. 

3  J.6  Process  Models 

Process  models  have  extended  beyond  the  input-control-output  characterization  of 
a  process  to  include  formal  description  of  the  actions  taken  to  effect  the  process.  Process 
modeling  is  a  common  practice  in  designing  or  validating  an  integrated  system,  but  there 
are  as  yet  no  standards  for  formal,  on-line  characterization  of  a  process  model.  Leading 
edge  organizations  have  developed  proprietary  formats  to  represent  their  process  models 
and  are  using  the  models  to  manage  the  automated  portions  of  their  integrated  enterprise. 

3.3.7  Adaptive  Interface  Technology 

Adaptive  interface  technology  provides  an  object-oriented  mechanism  enabling 
data  servers  and  clients  to  exchange  data,  requests,  and  responses.  Adaptive  interface  tech¬ 
nology  is  required  because  users  have  realized  that  the  value  of  information  depends  on 
proper  use  of  data  in  context  Data  is  owned  by  a  server  that  acts  as  the  steward  of  that  data 
and  of  the  information  that  it  represents.  The  steward  provides  access  to  the  data,  or  trans¬ 
fers  the  data  to  a  user's  system.  In  addition,  the  steward  responds  to  queries  about  how  to 
interpret  the  data,  and  the  steward  performs  services  on  the  data  in  response  to  client 
requests.  Available  services  are  published  by  the  steward  as  a  standard  set  of  interfaces  that 
can  be  used  to  request  services  and  other  descriptive  information. 

33.8  Operational  Integration  Frameworks 

Operational  integration  frameworks  provide  the  architecture  within  which  a  server 
publishes  the  services  it  provides.  These  frameworks  may  be  acquired  in  the  open  market¬ 
place  and  are  built  to  standards.  Framework  standards  specify  common  services  that  must 
be  offered  by  all  servers,  generic  services  such  as  open,  close,  print,  and  describe.  These 
frameworks  are  network  resource  managers  for  the  enterprise  and  are  provided  as  a  net¬ 
work  layer  of  the  operating  system  (much  as  network  file  systems  are  today).  Application 
frameworks  contains  extensions  that  are  services  applicable  within  a  specific  application 
domain.  An  example  would  be  an  electronic  CAD  Framework,  with  services  for  various 
design  views.  There  may  be  cross-cutdng,  application-oriented  frameworks  as  well.  An 
example  would  be  a  frtimework  for  simulations,  design  of  experiments,  and  their  analysis. 
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3.3.9  Autonomous  Systems 

Autonomous  systems  are  composed  of  many  actors,  each  carrying  out  a  process  in 
the  value  chain  of  the  enterprise,  and  stewards,  each  managing  one  view  of  a  part  of  the 
enterprise.  Adaptive  interfaces  enable  these  independent  computations  to  collaborate  in 
achieving  the  common  integration  of  the  enterprise.  But  each  computation  is  in  some  sense 
autonomous.  One  sense  in  which  a  computation  is  autonomous  is  that  a  steward  process 
owns  the  data  that  it  serves  and  will  prevent  inappropriate  manipulation  of  that  data  by  tak¬ 
ing  unilateral  actions  if  necessary.  Another  sense  in  which  a  computation  is  autonomous  is 
that  it  is  shielded  from  activities  in  the  integrated  system  that  are  irrelevant  to  its  own  role. 

3  J.10  Software  Development  Environments  for  Autonomous  Systems 

Programming  an  autonomous  system  requires  software  development  environments 
that  provide  framework  fixtures  to  emulate  the  environment  of  the  computation  under 
development,  including  monitoring  its  behavior  against  formal  specifications.  Different 
computations  in  an  integrated  system  can  run  on  difrerent  processors  in  a  multiprocessor 
workstation  or  on  different  processors  across  the  network.  In  this  environment,  compilers 
produce  executable  code  that  is  linked  dynamically  with  the  service  communication  inter¬ 
face  provided  by  the  run-time  framework.  Software  developers  use  network-oriented,  com- 
municadons-oriented  parallel  debuggers. 
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4.  CURRENT  STANDARDIZATION  AND 
COOPERATIVE  EFFORTS 


Standards  are  important  to  information  integration.  The  study  team  has  developed 
a  baseline  of  current  standards  and  cooperative  efforts  to  support  the  achievement  of  indus¬ 
trial  information  infrastructures  for  enterprise  integration.  During  the  study  the  team  set  out 
to: 

•  Identify,  organize,  and  present  available  technology  components  from  which  a 
U.S.  information  integration  strategy  can  be  coalesced;  these  technology  com¬ 
ponents  are  derived  from  current  standards  and  from  standardization  and  pre- 
standardization  efforts. 

•  Identify  specific  opportunities  to  accelerate  the  development  and  adoption  of 
components  and/or  to  increase  the  likelihood  of  their  success. 

4.1  BASELINE  REPORT 

A  companion  study,  IDA  Document  D- 1386,  Current  Standardization  and  Cooper¬ 
ative  Efforts  Related  to  Industrial  Information  Infrastructures,  provides  an  assessment  of 
key  standards  and  technologies  that  will  be  required  over  the  next  10  years  to  build  the  nec¬ 
essary  components  of  an  information  infrastructure.  It  establishes  a  baseline  of  85  standards 
and  technologies.  Both  public  and  proprietary  standards  are  reviewed  since  important  con¬ 
tributions  to  an  information  infrastructure  will  come  from  both  sources.  A  brief  description 
of  each  standard  and  technology  is  provided  and  its  importance  to  information  integration 
is  assessed  along  with  its  current  status.  This  assessment  provides  insight  in  developing 
strategies  for  the  most  critical  standards  and  technologies  that  will  be  required  for  estab¬ 
lishing  a  successful  information  infrastructure.^^ 

The  baseline  report  also  profiles  27  organizations  and  programs  that  develop  or  sup- 
port  the  standards  and  technologies  identified.  The  organizations  and  programs  are 

For  another  view  of  an  overlapping  set  of  standards,  see  Sarah  H.  Nash  and  Robert  P.  Walker,  A  Survey  of 
Technical  Standards  for  Command  and  Control  hrformation  Systems,  Eiecember  1992,  Alexandria,  VA, 
Institute  for  Defense  Analyses.  IDA  Paper  P-280S.  Draft 


described  in  terms  of  who  is  involved,  what  they  are  doing  and  how  they  link  to  other  orga¬ 
nizations  and  programs.  Understanding  the  key  players  and  their  roles  is  important  in 
developing  an  appropriate  strategy. 

The  report  relates  organizations  and  programs  to  standards  and  technologies  by 
summarizing  their  standards  deployment  (technology  development  and  market  building) 
activities.  For  this  purpose  and  others  in  the  report,  standards  and  technologies  are  grouped 
into  10  technical  categories  based  on  the  Advanced  Manufacturing  Technology  (AMT) 
Standards  Reference  Model. 

a.  Integration  Frameworks^*  and  Architectures:  Overall  integrating  representa¬ 
tions,  models,  and  schemata  of  the  enterprise  and  its  component  parts. 

b.  Operating  Systems  and  Distributed  Environments:  Components  used  to  provide 
system  services  to  applications. 

c.  Communications:  Components  used  to  cciinect  applications,  allowing  applica¬ 
tions  to  transfer  data  and  control  among  themselves. 

d.  Data  Management  Systems:  Components  used  to  store,  manage,  and  retrieve 
data. 

e.  User  Interface:  Components  that  allow  users  to  interact  with  applications  making 
up  the  integrated  enterprise. 

f.  Information  Modeling  Tools  and  Methods:  Tools  and  methods  used  to  construct 
models  of  the  enterprise  and  its  components. 

g.  Application  Development  Tools  and  Methods:  Tools  and  methods  used  to  model 
and  build  applications. 

h.  Security  Tools  and  Methods:  Tools  and  methods  used  to  control  access  to  appli¬ 
cations  and  data. 

i.  Data  Representations:  High-level  data  representation  standards. 

j.  Programming  Languages:  High-level  languages  used  to  represent  algorithms 

Using  the  baseline  data,  a  number  of  useful  questions  concerning  the  status  of  stan¬ 
dards,  technologies,  organizations,  and  programs  relevant  to  information  infrastructures  for 
enterprise  integration  can  be  answered  directly.  Examples  of  such  quesdons  include  the  fol¬ 
lowing: 

Note  that  this  is  the  usage  from  the  AMT  category  list.  It  is  substantially  more  general  than  the  notion  of 
Operational  integration  Frameworks  as  described  in  Section  3.3.8. 
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•  What  organizations  and  programs  are  concerned  with  information  modeling? 

•  What  standards  and  technologies  are  proposed  or  in  place  concerning  user  inter¬ 
faces? 

•  What  organizations  and  programs  are  involved  with  POSIX  (Portable  Operating 
System  Interface  for  Computer  Environments),  and  what  are  their  interests? 

Other  questions,  such  as  which  of  the  standards  and  technologies  are  most  critical 
to  success  in  implementing  a  National  Information  Infrastructure,  and  what  are  their  current 
'Status,  require  further  analysis  and  often  additional  data.  The  specific  analytic  techniques 
needed,  of  course,  depend  on  the  question  being  asked.  This  report  presents  an  example 
analysis  of  this  last  question,  in  the  next  section,  to  demonstrate  the  types  of  analyses  pos- 
.sible  with  the  baseline  data. 

4.2  EXAMPLE  ANALYSIS  OF  CRITICAL  STANDARDS  AND  TECHNOLO¬ 
GIES 

The  approach  is  to  relate  the  baseline  standards  and  technologies  to  business  needs. 
This  relationship  is  established  in  a  two-step  process,  first  relating  business  needs  to  activ¬ 
ities  that  an  integrated  enterprise  may  undertake  to  satisfy  those  needs,  and  then  relating  the 
activities  to  supporting  technical  categories  and  standards  and  technologies  within  catego¬ 
ries.  The  analysis  presented  here  is  based  upon  work  done  by  the  Enterprise  Integration 
Program  (EIP)  Needs  Analysis  team  and  makes  use  of  the  Quality  Function  Deployment 
(QFD)  methodology. 

The  concept  of  QFD  is  to  relate  “what  the  customer  wants”  (needs  and  require¬ 
ments)  to  “how  product  features  meet  those  wants”  (solutions).  A  chart  is  used  to  record 
the  evaluation  of  how  each  solution  contributes  to  each  need  or  requirement.  QFD  supports 
decomposition,  in  that  a  solution  at  a  higher  level  can,  in  turn,  be  considered  a  need  at  a 
lower  level  of  analysis. 

In  this  study,  “what  the  customer  wants”  related  to  “how  product  features  meet 
those  wants”  translates  at  the  first  level  into  “business  needs”  related  to  “activities,”  and  at 
the  second  level  into  “required  activities”  related  to  “standards  and  technologies,”  using 
material  from  the  Enterprise  Integration  Program  Needs  Analysis  team  (see  Figure  5).  The 
baseline  standards  and  technologies  relate  to  aspects  of  successful  standards  development 
and  deployment,  using  criteria  from  the  NIST  APP  (Application  Portability  Profile)  and  the 
POSIX  OSE  (Open  Systems  Environment),  with  some  additional  criteria  by  the  study  team. 
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Figure  5.  Relating  Business  Needs  to  Standards  and  Technologies 


The  results  of  the  QFD  analysis  are  presented  in  Figures  1»  2,  and  3  of  IDA  Docu¬ 
ment  D-1 386,  Current  Standardization  and  Cooperative  Efforts  Related  to  Industrial  Infor¬ 
mation  Infrastructures,  and  are  summarized  in  Table  4.  For  most  technical  categories,  a 
small  number  of  standards  and  technologies  dominate.  The  standards  and  technologies  are 
divided  into  two  major  groupings;  Proprietary  and  Open.  The  following  paragraphs  sum¬ 
marize  the  analysis  of  the  key  standards  and  technologies  for  each  category. 

Integration  Frameworks  and  Architectures.  This  category  is  characterized  by  a 
relative  absence  of  standards  activity.  The  CAD  Framework  Initiative  (CFI)  is  one  of  the 
few  open  systems  efforts,  but  it  is  currenUy  limited  to  a  particular  application  area.  An 
open,  non-proprietary  framework,  similar  to  SAA  (Systems  Application  Architecture), 
NAS  (Network  Application  Support),  GM-C4,  or  NewWave,  is  yet  to  be  developed.  The 
NIST  APP  is  a  start,  though  it  tends  to  be  a  collecting  framework  rather  than  an  integrating 
one.  Proprietary  solutions  are  beginning  to  appear  and  there  are  related  research  efforts. 

Operating  Systems  and  Distributed  Environments.  Three  different  types  of 
functional  subareas  require  attention:  traditional  operating  systems,  distributed  environ¬ 
ments,  and  distributed  object  management  systems.  Assuming  that  current  micro-kernel 
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Table  4.  Important  Standards  and  Technologies  by  Cat^ory 


Category 


Information 
Frameworks  and 
Architectures 

Operating 
Systems  and 
Distributed 
Environments 

Communications 


Data  Management 
Systems 


Application 
Development 
Tools  and 
Methods 


Data 

Representation 

Information 
Modeling  Tools 
and  Methods 

User  Interfaces 


Programming 

Languages 


Security  Tools  and 
Methods 


Proprietary 


Open 


u 

u 

e 

1 

O 

U 

c  c 

f/i 

V 

V 

o 

S  = 

o 

o. 

B 

CQ 

ta  •— 

C 

o  -ts 

o 

Ui 

3 

2 

B 

A 

B 

z 

O.  ^ 

eo 

CO 

z 

mm 

B 

E 

category 


( 


efforts  like  the  Mach  operating  system  project  are  viewed  as  implementations  rather  than 
standards,  Unix  derivatives  are  the  primary  contenders  for  the  traditional  operating  system. 
SVR4  from  Unix  International  and  OSF/1  from  the  Open  Software  Foundation,  both  of 
which  reference  the  POSIX  standard,  scored  highly  in  this  evaluation.  The  many  Unix 
derivatives  being  developed  emphasize  the  importance  of  moving  the  POSIX  efforts  for¬ 
ward  so  that  a  common  standard  exists.  Both  SVR4  and  OSF/1  are  beginning  to  develop 
capabilities  to  support  distributed  environments  as  well.  A  key  contributor  in  this  area  is 
the  ISO  in  its  Open  Distributed  Processing  (ODP)  effort  to  develop  a  reference  model  for 
future  distributed  processing  standards.  Distributed  object  management  is  also  emerging  as 
a  critical  technology  for  the  future.  IBM  has  developed  OO-CORE  to  support  object  man¬ 
agement.  The  Object  Management  Group  (OMG)  is  also  heavily  involved  in  promoting 
object  standards  (such  as  the  Common  Object  Request  Broker  Architecture,  or  CORBA). 

Communications.  The  need  for  standards  in  the  area  of  communication  has  long 
been  recognized.  The  Open  System  Interconnection  (OSI)  family  of  standards  (e.g.,  MAP/ 
TOP,  GOSIP — the  Government  OSI  Profile)  dominates  this  category.  TCP/IP  (which  was 
often  the  third  member  of  the  list)  must  also  be  considered  both  because  of  its  large  installed 
base  and  open  nature.  The  OSI  standards  define  more  functionality  than  TCP/IP,  but  TCP/ 
IP  is  on  a  trajectory  where  it  is  continuing  to  adopt  OSI  functionality.  It  is  still  seen  by  many 
as  an  interim  step  to  full  OSI  compatibility. 

Data  Management  Systems.  The  first  ANSI  IRDS  standard  (IRDSl)  is  based  on 
the  relational  model.  It  defines  the  information  captured  by  an  Information  Resource  Dic¬ 
tionary  as  well  as  the  services  provided  by  enterprise  processing  facilities.  Future  object- 
oriented  systems  are  focusing  on  the  second  IRDS  standard  under  consideration.  The  high 
level  of  interest  in  this  work  indicates  the  importance  of  this  relatively  young  effort.  The 
Remote  Database  Access  (RDA)  protocol  is  seen  as  an  important  standard  to  enable  the 
operation  of  distributed  databases.  Object-Oriented  SQL  (00-SQL),  an  object-oriented 
extension  to  SQL,  is  used  as  the  data  manipulation  language  developed  by  IBM  as  part  of 
its  OO-CORE  project  The  importance  assigned  to  00-SQL  and  OO-CORE  indicates  the 
need  to  bring  these  technologies  into  the  public  arena  where  an  open  evolution  process  can 
take  place. 

Application  Development  Tools  and  Methods.  The  X/Open  APIs  define  a  tool  kit 
of  program  interface  calls  across  a  number  of  functional  areas.  This  effort  stands  out  in  its 
effect  on  architectural  and  business  needs.  However,  other  useful  tools  and  methods  are 
proprietary  in  nature,  such  as  application  generators  and  knowledge-based  systems. 
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Although  seen  as  important,  there  are  no  visible  standards  activities  associated  with  these 
areas. 

Data  Representation.  This  area  has  also  experienced  intense  standards  activities. 
There  are  many  different  domain-specific  data  representation  standards.  Combining  scores 
across  a  spectrum  of  requirements  emphasizes  those  standards  that  have  the  broadest 
intended  scope  such  as  STEP  (the  Standard  for  the  Exchange  of  Product  Data).  STEP  is  an 
important  ISO  effort  bringing  together  several  national  efforts  to  build  an  engineering  data 
exchange  specification.  Much  work  remains  in  the  development  of  Application  Protocols 
and  test  tools.  Other  important  representation  standards  include  the  ANSI  EDI  standards 
for  exchanging  business  documents,  SGML  for  document  markup,  the  Programmer’s  Hier¬ 
archical  Interactive  Graphics  System  (PHIGS)  which  is  a  three-dimensional  graphics  stan¬ 
dard,  and  the  Computer  Graphics  Metafile  standard  (CGM)  which  defines  a  graphics  file 
format. 

Information  Modeling  Tools  and  Methods.  IDEFO  and  IDEFlx  are  important 
standards  for  process  and  data  modeling  for  large  organizations.  There  are,  however,  many 
different  modeling  tools  available.  SUMM  is  an  effort  to  define  the  mechanisms  that  will 
allow  integration  of  data  models  and  schema  defined  by  various  modeling  languages. 
Knowledge-based  systems  are  also  being  used  for  information  modeling,  but  no  significant 
standards  activity  could  be  found  on  this. 

User  Interfaces.  X-Windows  is  a  key  standard  and  is  also  found  integrated  with 
higher-level  functions  in  Motif  and  Open  Look.  Motif  (OSF)  and  Open  Look  (Unix  Inter¬ 
national)  provide  extensive  libraries  for  building  graphical  user  interfaces.  The  IEEE 
POSDC  1201  effort  is  important  because  it  is  attempting  to  build  a  single  common  applica¬ 
tion  interface  (using  the  Extensible  Virtual  Tool  kit,  XVT)  that  sits  above  Motif  and  Open 
Look. 

Programming  Languages.  This  area  already  has  a  number  of  well-developed  stan¬ 
dards  and  technologies  (Ada,  C,  Cobol,  Fortran,  Lisp),  and  primarily  needs  only  mainte¬ 
nance.  Extensions  for  objects  (e.g.,  C++)  or  APIs  (e.g.,  X/Open)  are  the  key  development 
activities. 

Security  Tools  and  Methods.  IEEE  POSDC  1003.6  is  a  key  standard  under  devel¬ 
opment.  It  is  intended  to  provide  comprehensive  security  access  and  control  for  applica¬ 
tions.^^  Data  Encryption  Standard  (DES)  is  an  encryption  standard  that  is  now  part  of 
GOSIP. 
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An  artifact  of  using  a  broad  (business  or  technical)  requirements-driven  method  is 
that  the  results  emphasize  those  standards  and  technologies  that  are  more  broadly  based. 

However,  any  strategic  plan  must  consider  the  difficulty  of  integrating  these  standards  and 
technologies  with  the  legacy  of  existing  and  future  proprietary  solutions.  Systems  based  on 
today’s  operating  systems  (MS-DOS,  VMS,  Unix),  windowing  environments  (MS-Win¬ 
dows,  Macintosh,  X-Windows),  and  networks  (Novell  and  TCP/IP)  must  be  able  to  fit  with¬ 
in  the  information  integration  infrastructure.  In  fact,  there  has  been  some  success  mixing 
these  principal  components  to  construct  usable  information  infrastructures.  A  U.S.  indus¬ 
trial  information  infrastructure  must  support  these  and  other  very  popular  technologies. 

4.3  CONCLUSIONS  AND  ISSUES 

The  analysis  of  critical  standards  and  technologies  and  their  current  status  presented 
here  is  heavily  dependent  on  the  choice  of  framework  or  reference  model  for  expressing 
“what  the  customer  wants.”  The  use  of  requirements  derived  from  business  needs,  as  in  the 
EIP  Needs  Analysis  task,  can  be  defended  as  reflecting  the  wants  and  perceptions  of  those 
who  must  ultimately  pay  the  bill  for  enterprise  integration.  It  also  includes  the  organization¬ 
al,  procedural,  and  personnel  aspects  of  enterprise  integration,  as  well  as  the  technical  ones. 

Also,  this  analysis  takes  a  broad  view  of  the  importance  of  standards  and  technolo¬ 
gies  in  meeting  the  general  needs  of  an  information  infrastructure.  It  does  not  differentiate 
between  standards  and  technologies  with  a  broad  scope  and  those  addressing  a  narrow  set 
of  requirements.  With  those  caveats,  some  general  conclusions  can  be  reached: 

a.  Operating  systems,  distributed  environments,  integration  frameworks,  and 

architectures  are  critical  foundation  technologies  that  must  be  established.  These 
categories  scored  the  highest  across  all  evaluation  frameworks.  Several  poten¬ 
tially  important  standards  and  technologies  were  identified.  Since  much  of  the 
work  in  this  area  is  proprietary  or  consortial,  there  is  still  a  need  to  promote  stan¬ 
dards  in  these  areas.  The  lack  of  unifying  standards  may  lead  to  market  fragmen-  ' 

ration  that  will  slow  the  development  of  an  information  integration 
infrastructure. 

b.  Data  management,  communications,  and  data  representation  standards  and  tech- 
nologies  are  next  in  importance.  The  information  infrastructure  requires 
standards  that  support  highly  integrated  information  management  systems 

^‘But  see  the  discussion  in  Section  A.3,  SECURITY  RISK  MANAGEMENT  AND  INTEGRATED 
ENTERPRISE  INFORMATION  PROTECTION,  in  Appendix  A,  for  a  broader  view  of  this  issue.  * 
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across  the  entire  enterprise.  The  need  for  standards  in  these  areas  has  long  been 
recognized  as  evidenced  by  the  preponderance  of  standards  available.  There  is 
)  still  a  need  to  organize  these  standards  into  a  consistent  framework  and  to  ensure 

that  they  are  compatible. 

c.  Other  categories  such  as  application  development  tools  and  methods,  security 
tools  and  methods,  user  interfaces,  information  modeling  tools  and  methods,  and 
I  programming  languages  are  also  important.  Standards  and  technologies  in  some 

of  these  categories  are  more  important  in  the  development  of  applications.  Since 
this  report  focused  on  an  information  infrastructure,  they  did  not  score  very  high. 

The  importance  of  integration  frameworks  supports  the  necessity  of  identifying  a 
^  reference  model  that  can  be  used  to  guide  the  selection  of  standards  and  technologies  for 

an  integrated  information  infrastructure.  A  detailed  reference  model  identifies  the  major 
architectural  elements  of  the  information  system  and  their  interrelationships.  It  also  pro¬ 
vides  a  framework  for  identifying  needed  interface,  representation,  or  other  standards.  It 
^  provides  an  organizing  structure  that  helps  to  characterize  the  standards  and  technologies 

and  their  relationships. 

The  need  for  a  reference  model  is  widely  recognized.  As  a  result  several  activities 
are  developing  reference  models  in  this  area,  including  proprietary  models  (GM  C4),  ven¬ 
dor  models  (EIS  Working  Group  (EISWG)),  and  standards  efforts  (CIM/OSA).  Consensus 
is  needed  around  a  single  reference  model  (or  group  of  related  models)  from  which  a  coher¬ 
ent  set  of  standards  can  be  developed.  These  models  must  be  driven  from  clearly  articulated 
and  prioritized  business  needs.  The  information  in  this  report  and  its  companion  report, 
IDA  Document  D-1386,  Current  Standardization  and  Cooperative  Efforts  Related  to 
Iriustrialirtformation  Itffrastructures,  lays  the  foundation  for  capturing  some  of  these  crit¬ 
ical  business  drivers.  Future  tasks  should  look  at  how  well  these  business  needs  are  cap- 
^  tured  in  current  and  emerging  reference  models. 

A  single  reference  model,  with  its  benefits  for  analysis  and  decision-making,  does 
not  imply  a  single  view  of  information  integration.  Bu^ess  needs  vary  with  the  corpora¬ 
tion,  its  market  sectors,  and  its  strategies.  It  is  uitlikely  that  a  single  set  of  standards  will 
p  emerge  to  fit  all  these  varying  needs.  Still  a  well-designed  reference  model  can  support  pro¬ 

files  of  standards  suited  for  different  needs  (such  as  the  use  of  the  OSl  reference  model  for 
communications  standards).  Future  analysis  should  look  at  this  question  in  greater  detail. 
Business  needs  should  be  captured  for  different  segments  of  the  industry  in  order  to  identify 
^  the  major  profiles  that  may  be  required  to  meet  those  needs. 
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Further,  at  least  in  the  context  of  a  national  information  infrastructure,  other 
demands  besides  those  of  industrial  enterprise  integration  will  help  shape  the  infrastructure. 
A  national  information  infrastructure  is  viewed  by  many  as  doing  .  for  the  flow  of  infor¬ 
mation — words,  music,  movies,  medical  images,  manufacturing  blueprints,  and  much 
more — what  the  transcontinental  railroad  did  for  the  flow  of  goods  a  century  ago  and  the 
interstate  highway  system  did  in  this  century... (It  can  be]  a  national  resource  that  would 
improve  education,  health  care,  scientific  research,  and  the  ability  of  corporations  to  com¬ 
pete  in  the  world  economy,  among  many  other  things.”^^  To  the  extent  that  analogies  with, 
for  example,  the  interstate  highway  system  can  be  accurate,  then  unanticipated  uses  of  the 
infrastructure  and  resulting  major  changes  in  the  way  the  nation  lives  and  works  will  occur. 
Some  of  these  uses  and  changes  will  come  from  the  industrial  sector,  and  be  adopted  by 
others.  But  others,  equally  attractive,  will  come  from  outside  of  industry  and  be  adopted  by 
tliat  sector.  It  is  important  that  any  reference  model  be  flexible  enough  to  incorporate  this 
pattern  of  infrastructure  development. 

From  a  standardization  point  of  view,  three  areas  for  future  work  emerge  from  this 

study: 

•  Redo  analysis  with  common  reference  model. 

•  Assess  compatibility  of  standards. 

•  Determine  missing  standards  and  technologies. 

As  critical  standards  and  technologies  are  identified,  effective  deployment  strate¬ 
gies  must  be  put  in  place.  It  is  never  sufficient  to  simply  bring  a  standard  to  approved  inter¬ 
national  standard  status  or  to  prototype  the  technology.  The  Deployment  Forces  Tables  and 
the  Standards  and  Technology  Status  Matrix  in  IDA  Document  D-1386,  Current  Standard¬ 
ization  and  Cooperative  Efforts  Related  to  Industrial  Information  Infrastructures,  identify 
some  of  the  activities  and  issues  which  determine  the  success  or  failure  of  a  standard  or 
technology.  A  strategy  to  deploy  critical  information  technologies  must  take  these  issues 
into  consideration. 

It  is  important  to  maintain  a  sense  of  timing  and  evolution  about  infrastructure 
development.  The  U.S.  Air  Force’s  Enterprise  Integration  program  is  an  effort  focused  on 
identifying  appropriate  responses  to  near-term  demands  for  information  integration.  Likely, 

“Building  the  Electronic  Supeihighway,”  New  York  Times,  January  24, 1993.  Much  has  been  written  since 
this  article  presenting  various  visions  of  the  Nil.  Nevertheless,  the  goals  stated  in  this  article  are  widely 
accqrted  among  those  directly  interested  in  the  effort  to  create  a  new  national  information  infrastructure. 
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these  responses  will  take  the  form  of  finding  ways  to  use  existing  and  near-term  standards 
and  technologies  more  effectively.  The  anticipated  needs  10  years  or  more  in  the  future 
appear  to  require  the  development  of  new  technologies  and  architectures  leading  to  systems 
of  autonomous  modules.  The  development  of  strategies  and  methods  for  aiding  the  transi¬ 
tion  towards  these  forms  of  information  integration  must  be  planned  and  pursued. 
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5.  PRINCIPAL  FINDINGS  AND  CONCLUSIONS 
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During  the  study  many  facts  emerged  that  reflect  the  state  and  trends  of  current 
industry  efforts  to  integrate.  From  these  facts  the  study  team  derived  42  general  findings.^** 
Eight  principal  findings  stand  out  as  summarizing  the  experiences  reported  by  a  number  of 
companies.  These  principal  findings  are  presented  in  Section  5.1. 

Based  on  review  and  analysis  of  this  material,  the  study  team  developed  several 
conclusions  summarizing  progress  in  enterprise  integration  and  limitations  of  current 
approaches,  the  relationship  of  these  efforts  to  a  National  Information  Infrastructure  and  to 
national  economic  goals,  and  DoD's  position  and  potential  in  enterprise  integration.  These 
conclusions  arc  presented  in  Section  5.2. 

5.1  PRINCIPAL  FINDINGS 

Extent  of  Enterorise  Integration 

Companies  are  making  significant  commitments  and  executing  large  efforts  in  the 
direction  of  enterprise  integration.  Significant  results  are  being  achieved,  and  companies 
now  realize  that  achieving  significantly  more  is  feasible. 

Justification  for  Enterprise  Integration 

The  justifications  reported  for  investing  in  enterprise  integration  tended  to  be  intu¬ 
itive,  expressed  in  terms  of  competitive  necessity  and  a  sense  of  potential  quality  improve¬ 
ment  and  cost  reduction,  rather  than  the  traditional  cost-benefit  analysis. 

Incremental  Approach 

Most  of  the  companies  studied  are  implementing  an  incremental  “continents  of  inte¬ 
gration”  strategy  to  support  integration  goals.  They  are  moving  from  large  numbers  of 
loosely  coupled  activities  and  disconnected  information  systems  (“islands  of  automation”) 
to  a  small  number  of  large  islands  (“continents”).  Factors  dictating  this  strategy  include  a 

The  complete  general  findings  are  presented  in  Appendix  A. 


75 


general  lack  of  experience  and  scientific  knowledge  relevant  to  integration,  the  need  to 
include  legacy  systems,  and  the  existing  organizational  environment. 


Current  Culture.  Infrastructure  as  Barriers 

Corporate  culture  and  current  infrastructure  are  widely  viewed  as  the  dominant  bar¬ 
riers  to  progress  in  enterprise  integration.  Current  infrastructures  are  not  constrained  by  the 
state  of  technology,  except  possibly  for  integration  frameworks  and  architectures.  The  com¬ 
panies  visited  want  more  integrated  infrastructures  both  because  the  current  infrastructure 
is  viewed  as  a  barrier  to  integrated  activities  and  because  an  integrated  infrastructure  would 
facilitate  the  information  sharing  on  which  integrated  activities  depend. 

Role  of  Management  Sponsor 

Several  companies  reported  that  a  high-level  sponsor  is  critical  for  moving  forward 
successfully  with  enterprise  integration.  The  sponsor,  typically  a  president  or  a  vice-presi¬ 
dent,  needs  to  be  in  the  common  chain  of  command  in  order  to  resolve  impasses  between 
groups,  and  to  smooth  management  delays  between  the  project  management  level  and  the 
sponsor’s  level.  This  sponsor  tended  to  be  the  Least  Common  Manager  above  the  groups  to 
be  integrated.  Only  very  strong,  constant,  and  visible  top  leadership  can  overcome  cultural 
barriers  of  the  sort  commonly  encountered. 

Change  Management  a  Critical  Problem 

Management  of  change  and  the  required  evolvability  of  information  infrastructures 
are  critical  problems  for  all  companies  studied.  Changes  range  from  very  large  to  highly 
focused,  and  may  be  ad  hoc  or  permanent.  Changes  affect  the  structure  and  content  of  both 
information  and  control  flows,  in  both  the  human  and  the  automated  sides  of  the  enterprise. 
Most  implementers  regard  assistance  with  change  management  as  a  key  goal  of  informa¬ 
tion  integration.  They  require  system  solutions  that  are  designed  and  implemented  to  facil¬ 
itate  change  in  the  infrastructure  itself. 

Role  of  Standards 

While  recognizing  the  benefits  of  widely  accepted  standards  for  enterprise  integra¬ 
tion,  none  of  the  companies  studied  are  waiting  for  the  development  of  appropriate  stan¬ 
dards.  All  are  proceeding  with  enterprise  integration  using  available  products  and 
technology,  developing  company-unique  solutions  where  needed.  Nevertheless,  companies 
expressed  a  widespread  desire  for  appropriate  standards. 
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If  the  demand  for  standards  were  articulated  with  sufficient  focus,  strength,  and 
indication  of  priorities,  a  focused  response  from  the  vendors  would  be  elicited.  Only  a  few 
of  the  studied  companies  prefer  to  rely  on  internally  created  systems  with  company-specific 
data  representations,  usually  in  search  of  a  strategic  advantage.  In  most  cases  vendors  have 
an  interest  in  widely  accepted  standards  and  would  prefer  their  existence. 

Lack  of  Scientific  Knowledge  and  Accepted  Engineering  Practice 

While  increasingly  complex  integrated  systems  are  being  implemented,  the  under¬ 
standing  of  scientific  and  engineering  issues  inherent  in  such  systems  is  generally  weak. 
Suggested  ways  to  increase  understanding  include  continued  industrial  efforts  such  as  those 
reported  in  this  study,  demonstrations  of  new  approaches  in  realistic  settings,  academic, 
government  and  industrial  research,  and  development  of  new  integration  technology. 

5.2  PRINCIPAL  CONCLUSIONS 

Achievements  of  Current  Approaches  to  Enterprise  Integration 

The  achievements  of  U.S.  industry  in  implementing  enterprise  integration  should  be 
applauded.  Many  projects  have  been  undertaken,  by  many  firms,  with  promising  results. 
There  have  been  real,  significant  benefits  in  terms  of  quality  improvements,  cof;t  reductions, 
and  cycle  time  reductions.  These  achievements  should  be  acknowledged.  At  the  same  time, 
they  should  be  reviewed  in  terms  of  identifying  and  understanding  the  problems  and  limi¬ 
tations  revealed,  as  well  as  the  successes. 

Technical  Limitations  of  Current  Approaches 

The  incremental  “continents  of  integration”  approach  used  by  most  companies 
studied  has  enabled  successful  integration  in  uncertain  situations.  However,  it  has  several 
potential  drawbacks.  A  large  investment  in  an  “island”  may  create  an  inertial  barrier  against 
future  integration,  since  required  change  can  be  seen  as  devaluing  the  original  investment. 
Coordination  of  integration  efforts  across  “islands”  within  large  companies,  necessary  to 
ensure  a  consistent  evolvable  approach  to  integration,  is  typically  very  difficult.  Without 
providing  for  evolvability,  separate  “islands”  may  adopt  incompatible  infrastructure  mech¬ 
anisms,  thereby  incurring  either  re-implementation  costs  or  increased  system  maintenance 
costs.  Thus,  the  “continents  of  integration”  approach,  while  allowing  early  progress,  may 
be,  in  the  longer  term,  self-limiting. 
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The  absence  of  relevant  standards,  represented  in  products  obtainable  in  the  market, 
means  that  most  firms  are  achieving  integration  results  by  inventing  in  part  their  own  solu¬ 
tions  to  particular  problems.  While  this  approach  allows  progress  now  rather  than  delay  in 
waiting  for  the  market,  it  also  means  that  future  integration,  intra-firm  and  inter-firm,  may 
have  to  deal  with  the  results  of  successful  earlier  integration  efforts  as  legacy  systems,  to 
be  worked  around  or  converted  at  additional  cost. 

Formal  standards  are  more  important  for  inter-organization  enterprise  integration 
than  for  intra-organization  integration,  as  they  provide  an  accepted  alternative  to  negotiat¬ 
ing  unique  solutions  to  integration  problems.  As  time  passes  and  more  firms  integrate  inter¬ 
nally,  inter-organization  considerations  will  become  dominant. 

Undoubtedly,  holes  and  overlaps  exist  in  the  current  coverage  of  standards  for  var¬ 
ious  aspects  of  information  infrastructures.  The  lack  of  an  accepted  framework  or  reference 
model  for  information  infrastructures  makes  it  extremely  difficult,  if  not  impossible,  to 
identify  these  holes  and  overlaps.  The  absence  of  a  framework,  and  inconsistent  standards 
coverage,  will  become  increasingly  relevant  limitations  on  enterprise  integration  as  it 
expands  beyond  the  boundaries  of  individual  organizations.^^ 

Organizational  Limitations  of  Current  Approaches 

Companies  engaged  in  enterprise  integration  are  forming  an  internal  base  of  expe¬ 
rience,  but  this  learning  is  not  being  disseminated  widely.  Mechanisms  for  sharing  experi¬ 
ence  and  identifying  common  successes  and  failures  are  lacking.  In  the  longer  term, 
systematic  sharing  of  experiences  about  how  to  integrate  effectively  should  provide  a  real 
economic  benefit. 

With  some  notable  exceptions,  successful  inter-organization  enterprise  integration 
has  been  much  less  common  than  intra-organization  integration.  Why  is  this  so?  (Excep¬ 
tions  include  automotive  industry  supplier-manufacturer  integration  and  prime  contractor 
teams  for  military  aircraft  development,  and  have  tended  to  depend  on  use  of  homogeneous 
tools  or  platforms.) 

•  The  consensus  among  those  engaged  in  enterprise  integration  is  that  current  cul¬ 
tural  and  organizational  arrangements  present  the  most  significant  barriers  to 


These  issues  are  discussed  in  detail  in  IDA  Document  D-1386,  Current  Standardization  and  Cooperative 
Efforts  Related  to  Industrial  Information  Irtfrastructures. 
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progress.  In  most  cases,  present  technology  is  seen  as  meeting  present  integra¬ 
tion  needs. 


•  However,  overcoming  the  barriers  arising  from  organizational  culture  is  much 
more  manageable  within  a  single  organization  than  across  organizations. 

•  Within  hierarchical  organizations,  the  presence  of  a  high-level  management 
sponsor  can  work  to  resolve  issues. 

•  >^thin  project-oriented  organizations,  the  culture  typically  facilitates  coopera¬ 
tion  and  negotiation  as  the  preferred  method  for  solving  common  problems. 

•  Between  disparate  organizations,  mechanisms  for  dealing  with  conflict  are  not 
as  developed. 

•  As  enterprise  integration  expands  beyond  the  boundaries  of  any  single  organi¬ 
zation,  problems  of  conflict-resolution  in  the  context  of  disparate  organizational 
cultures  will  come  to  the  foreground,  and  resolution  techniques  beyond  mandat¬ 
ing  a  common  integration  platform  will  be  needed. 

Relation  to  Business  Objectives 

Successful  integration  activities  are  generally  those  that  follow  from  agreed-upon 
business  objectives  and  that  do  not  go  (to  far)  beyond  the  knowledge  basis  and  understand¬ 
ing  of  integration  available  to  the  enterprise. 

Relation  to  National  Information  Infrastructure 

Enterprises  using  the  National  Information  Infrastructure  will  often  be  using  that 
infrastructure  to  integrate  different  organizations.  Standards  coverage  is  thus  highly  rele¬ 
vant  to  successful  use  of  that  infrastructure.  There  is  a  strong  need  to  start  working  now 
toward  the  specification  and  adoption  of  one  or  more  integration  frameworks  and  architec¬ 
tures,  and  the  identification  of  weaknesses  in  standards  coverage. 

Relation  to  National  Economic  Goals 

Enterprise  integration  holds  promise  for  enhancing  the  competitiveness,  both  local¬ 
ly  and  globally,  of  U.S.  firms.  The  improvements  previously  depicted  in  Table  2  already 
realized  from  first  steps  toward  integration  have  demonstrated  that  promise.  Effective  par¬ 
ticipation  in  the  global  economy  requires  enterprise  integration  almost  by  definition.  This 
means  both  that  existing  multi-national  companies  are  a  source  of  experience  with  integra- 


tion  and  that  successfully  integrating  firms  are  likely  to  become,  if  not  multi-national  them¬ 
selves,  partners  of  multi-nationals. 

The  effect  of  enterprise  integration  on  employment  is  problematic.  Enterprise  inte¬ 
gration  viewed  as  automating  infomiation  and  control  processes  seems  likely  to  result  in 
the  same  job  reduction  result  as  is  being  experienced  in  other  areas  of  automation.  At  the 
same  time,  achieving  enterprise  integration  requires  the  development  and  deployment  of 
many  new  hardware  and  software  products,  involving  a  great  deal  of  skilled  problem  solv¬ 
ing.  Efforts  to  deal  with  job  displacement  and  retraining  need  to  be  sensitive  to  these 
effects,  both  of  potential  job  loss  and  the  need  for  new  skills. 

DoD's  Position  and  Role 

In  many  senses  DoD  is  the  prototypical  enterprise,  with  multiple  suppliers,  numer¬ 
ous  customer  programs,  highly  technical  and  information-flow  dependent  products  and 
processes,  people  and  operations  physically  located  throughout  the  world,  and  a  complex 
internal  organization.  As  such,  DoD  stands  to  benefit  greatly  from  enterprise  integration. 
And  DoD  can  expect  the  same  problems  in  achieving  success  with  integration  as  other 
organizations.  For  example,  technology  will  not  be  the  problem;  culture  clashes  within  the 
organization  and  overcoming  the  existing  information  infrastructures  will. 

Today,  with  a  few  exceptions,  industry  is  well  ahead  of  the  DoD  in  successful  inte¬ 
gration.  The  DoD  has  much  more  difficult  hurdles  to  overcome  in  achieving  successful 
automation  than  most  enterprises.  The  DoD  must  place  relatively  more  emphasis,  early-on, 
on  inter-organization  integration,  which  can  be  significantly  harder  to  achieve  than  intra- 
organization  integration.  This  difficulty  is  further  aggravated  by  the  framework  of  legal  and 
procedural  limitations  within  which  the  DoD  must  operate.  Successful  integration  will 
demand  that  some  of  these  barriers  perceived  by  contractors  and  DoD  personnel  alike  be 
removed.  The  DoD's  potential  for  quality  improvement,  cost  reduction,  and  responsiveness 
improvement  are  commensurate  with  these  problems. 
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6.  RECOMMENDATIONS 


Enterprise  integration  makes  company  processes  such  as  design,  manufacturing, 
and  business  operations  (including  overhead  processes)  work  in  concert  to  become  more 
effective  and  efficient.  The  basis  of  enterprise  integration  is  the  interaction  of  integrated 
activities  (such  as  IPPD,  concurrent  engineering,  integrated  manufacturing)  and  integrated 
information  systems.  Applied  on  a  large  scale,  benefits  of  this  interaction  result  in  large  cost 
savings  and  shorter  times  to  field  systems  with  the  latest  technologies;  products  can  be 
developed  and  built  by  integrated  teams  formed  rapidly  to  meet  the  needs  of  defense  or 
civilian  customers.  As  shown  in  this  report,  the  benefits  can  be  dramatic  even  when  circum¬ 
stances  challenge  progress. 

DoD  efficiency  objectives — lower  costs,  shorter  schedules,  and  higher  quality  of 
DoD  products — can  be  achieved  by  enabling  industrial  implement ition  of  re-engineered 
and  integrated  processes  with  intense,  interactive  use  of  supporting  information  systems. 
While  there  arc  high-level  dialogues  on  implementation  of  integrated  and  re-engineered 
processes  (for  example,  recent  Defense  Science  Board  studies  on  IPPD),  there  is  inade¬ 
quate  high-level  dialogue  on  acceleration  of  integrated  information  systems  to  support  the 
proposed  new  processes. 

DoD  executives,  managers,  and  planners  should  recognize  that  improving  the  effi¬ 
ciency  of  industrial  processes  on  a  scale  to  benefit  DoD  and  the  national  economy  is  a  large 
but  approachable  issue.  Leading  practitioners  of  integration  point  out  that  tenacious,  multi¬ 
faceted  attacks  are  necessary  even  within  individual  companies.  The  DoD  should,  there¬ 
fore,  create  multiple  angles  of  approach,  in  the  Services  and  Agencies,  from  advanced  tech¬ 
nology  developments  and  demonstrations  through  pilot  implementations  and  various  styles 
of  insertions  into  acquisition  programs.  The  achievable  target  of  widespread  and  very  sig¬ 
nificant  efficiency  improvements  in  industry  and  DoD  acquisitions  is  important  and  should 
not  be  compromised  for  short-term  and  relatively  minor  investment  savings.  Coordination 
will  have  to  be  dynamic  and  flexible  in  order  to  identify  winning  approaches  and  propagate 
them.  In  this  way,  near-term  returns  on  investment,  such  as  those  experienced  in  the  cases 
reported  here,  can  be  achieved  and  expanded. 
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Strategies 

DoD  and  the  Services  can  encourage  and  enable  industrial  implementation  of  the 
required  processes  and  systems  by  implementing  the  following  strategies: 

•  Exert  leadership:  Use  the  National  Information  Infrastructure  initiative  to  create 
an  environment  for  industrial  information  integration;  create  rapid-response 
task  forces  for  government  and  industry  development  of  a  shared  vision  for  re¬ 
engineering  DoD  acquisition  processes,  information  requirements,  and  infor¬ 
mation  systems  that  are  traditionally  mirrored  by  the  defense  industry;  and  then 
implement  the  vision. 

•  Act  as  informed  customers  of  informed  suppliers:  Modify  acquisition  interfac¬ 
es,  information  deliverables,  and  incentives  to  create  a  “pull”  on  appropriate 
industry  acdons 

•  Form  partnerships:  Participate  in  coalitions  with  industry  to  accelerate  de  facto 
standards  and  to  support  selected  emerging  formal  standards  for  information 
system  interfaces  and  elements  (for  example,  design  representations  and  com¬ 
mon  network  services)  which  will  enable  information  system  integration  and 
accelerate  change 

•  Demonstrate,  and  advance  technologies:  Mitigate  the  risk  in  developing  high- 
risk  elements  needed  for  large-scale,  dynamic,  and  rapid  integration;  these  dem¬ 
onstrations  and  developments  will  advance  the  state  of  the  art,  provide  process 
performance  results  to  act  as  a  basis  for  industrial  adoption,  establish  directions 
for  vendor  products  and  network  services,  and  accelerate  technology  transition 
into  the  information  management  marketplace. 

The  specific  recommendations  are  organized  to  implement  these  strategies  through 
industry  and  DoD  actions.  The  findings  and  conclusions  of  this  study  show  that  the  reported 
benefits  derive  from  a  close  coupling  of  information  system  integration  with  process  re¬ 
engineering  to  address  cultural,  organizational,  and  policy  issues.  Although  the  study 
focused  on  information  systems  and  technologies,  findings  related  to  management  and  cul¬ 
ture  led  the  team  to  recommend  leadership  and  management  actions  to  move  forward  in  this 
critical  area. 


# 
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Implementations 

Two  implementation  approaches  should  be  applied,  usually  simultaneously,  to 
projects  started  in  response  to  the  specific  recommendations: 

•  Incremental  implementations:  Focus  on  part  of  the  process  first  and  then 
expand. 

•  Application-driven  implementations:  Focus  on  product-type-specific  processes 
first  and  then  generalize. 

Incremental  implementations  are  feasible  and  desirable  if  long-term  evolvability  is 
kept  as  a  critical  requirement.  For  example,  several  enterprises  have  started  their  imple¬ 
mentations  by  focusing  on  the  product  realization  process  from  the  engineering  process 
point  of  view.  Rapid  IPPD,  with  support  from  integrated,  distributed  product/process  engi¬ 
neering  frameworks,  tools,  and  information  bases,  can  be  implemented  based  on  existing 
methods  and  technologies  and  can  be  scaled  up  using  emerging  concepts  and  tools.  Another 
starting  point  is  in  integrated,  flexible  manufacturing  operations  with  incremental,  interac¬ 
tive  resource  planning,  intensive  information  linkages  with  suppliers,  and  real-time  inte¬ 
grated  factory  control.  Any  serious  effort  at  either  of  these  should  be  designed  for 
integration  with  the  other  so  that  efficient  design/manufacturing  trade-off,  feedback,  and 
change  management  would  be  possible.  BuUding  onto  these  foundations,  business  systems 
could  be  integrated  allowing  rapid  enterprise  resource  planning  (rather  than  just  manufac¬ 
turing),  strategic  trade-off  decisions,  and  fully  flexible  electronic  commerce. 

Second,  implementation  strategies  should  be  application  driven.  Past  efforts  have 
shown  that  generic  approaches  to  concepts  such  as  IPPD  are  seen  as  too  abstract  and  having 
limited  success.  Basing  the  implementation  of  information  technologies  for  enterprise  inte¬ 
gration  on  specific  product  types  or  sectors  will  yield  the  knowledge  required  for  generic 
solutions.  It  is  important,  however,  that  the  intent  to  generalize  be  represented  by  specific 
requirements  in  every  application-driven  program  and  that  mechanisms  be  established  to 
harvest  the  results  of  the  specialized  programs  and  to  develop  generic  approaches.  These 
mechanisms  should  be  planned  to  be  available  from  the  open  market  and  then  fed  back  into 
specific  product  developments. 

The  time  to  act  is  now.  The  technologies  to  start  the  process  are  available,  the 
approaches  to  be  explored  for  mid-  and  long-term  progress  have  been  identified  by  the  tech¬ 
nology  community,  the  past  approaches  that  form  barriers  to  integration  are  still  reversible. 
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the  need  for  integration  has  been  widely  recognized  in  industry,  and  the  climate  for  infra¬ 
structure  investment  by  government  is  favorable. 

Specific  Recomiiien<*ations 

The  following  specific  recommendations  are  derived  from  the  findings  and  conclu¬ 
sions  of  the  study  and  organized  according  to  the  above  listed  strategies.  They  are  directed 
no*,  only  to  the  inunediate  sponsors  of  the  study  (ARPA,  USAF  ManTech,  and  OSD  CALS) 
out  also  to  high-level  DoD  and  Service  management  and  industry  planners. 

«!■  «!■  «I«  ^ 

1.  Defense  Leadership 

1.1  ARPA  should  establish  a  focus  area  for  industrial  information  integration 
within  the  National  Information  Infrastructure  initiative. 

The  DoD.  through  ARPA's  participation  in  the  National  Information  Infrastructure 
(Nil)  effort,  has  the  opportunity  to  seed  the  technologies,  standards,  and  services  required 
for  wide-area,  scalable,  and  widely  used  industrial  information  integration.  In  addition  to 
the  traditional  focus  on  underlying  technologies,  such  as  high-speed  networks  and  commu¬ 
nications  protocols,  this  initiative  can  enable  ARPA  to  prototype  and  demonstrate  the  capa¬ 
bilities  required  to  address  the  compelling  national  issue  of  industrial  efficiency  and 
effectiveness.  Instead  of  using  application  areas  simply  to  motivate  underlying  technolo¬ 
gies,  ARPA  should  pay  considerable  attention  to  the  exploitation  of  the  infirastructure  by 
industrial  users  interested  in  leading  to  new  ways  of  doing  business.  There  is  technology 
available  now  to  begin,  and  there  are  open  technological  issues  to  be  explored  by  partner¬ 
ships  of  industry,  government,  and  research  organizations.  A  basis  for  beginning  is 
described  in  Recommendation  4. 1 .  These  new  industrial  uses  of  the  Nil  will  simultaneous¬ 
ly  stress  the  underlying  assumptions  of  the  prototype  networking  services  and  help  U.S. 
industry  understand  how  to  use  the  new  capabilities  to  maximum  advantage  for  internation¬ 
al  competitiveness.  The  result  will  be  a  better  and  more  immediately  useful  Nil  and  a  more 
efficient  U.S.  industrial  base. 
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12  DoD  and  the  Services,  working  with  industry,  should  establish  a  consensus 
vision  of  enterprise  integration  and  set  an  example  of  integration  within  their 
own  acquisition  processes. 

DoD  and  Service  acquisition  and  technology  organizations  should  stress  the  prior¬ 
ity  of  integrated  enterprises  and  integrated  information  systems  to  both  government  and 
industry.  To  make  this  credible,  DoD  and  the  Services  should  work  with  industry  to  set 
goals,  objectives,  and  characteristics  of  integrated  enterprises,  and  then  establish  a  phased 
program  to  both  re-engineer  government  acquisition  processes  and  integrate  supponing 
information  systems.  This  would  create  a  model  for  industry  and  provide  processes  and 
systems  to  which  industry  can  link.  Repeated  evidence  from  leading  companies  indicates 
that  sustained  commitment  by  the  OSD  and  Service  acquisition  and  technology  executives 
will  be  required  for  these  efforts. 

Scalable  integration  and  re-engineering  of  activities  and  integration  of  the  informa¬ 
tion  inftastructurc  arc  intertwined.  To  achieve  maximum  benefits,  top-level  industry  and 
government  executives  should  integrate  the  planning  and  execution  of  process  re-engineer¬ 
ing,  streamlined  business  practices,  and  information  management  improvements.  Within 
DoD,  current  actions  related  to  implementation  of  IPPD  by  the  Office  of  the  Secretary  of 
Defense  (OSD)  and  the  Services  can  serve  as  a  focus  for  actions  to  develop  and  implement 
integrated  information  systems.  These  actions  should  also  focus  on  integrating  the  informa¬ 
tion  requirements  from  contractors  (see  Recommendation  2).  This  approach  will  help  con¬ 
tractors  drive  toward  the  use  of  integrated  enterprises  on  DoD  projects.  The  systems  would 
initially  be  implemented  to  suppon  the  newly  integrated  processes  associated  with  EPPD 
implementation.  OSD,  USD(A),  and  the  Services  should  each  establish  appropriate  task 
forces  and  executive-level  directions  to  Initiate  planning  for  streamlined  processes  and  their 
integrated  information  systems.  Process  owners  should  be  engaged  by  OSD  and  Service 
managers  so  as  to  encourage  process  change. 

While  the  goal  of  the  above  is  across-the-board  rederign  of  acquisition  processes 
and  their  associated  information  management,  the  focus  on  IPPD  points  to  two  kinds  of 
focused  DoD  opportunities.  First,  the  front  end  of  acquisition,  as  executed  by  the  Science 
and  Technology  (S&T)  program,  can  be  reoriented  to  more  integrated  approaches  through 
the  use  of  new  advanced  technology  demonstrators  in  the  lead  programs  in  each  of  Thrusts 
1  through  5  and  7.  Then  the  MS&T  program  could  be  useo  uS  a  link  with  the  acquisition 
phases  beyond  S&T  through  a  set  of  pilot  programs  providing  high-visibility  examples  of 
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integrated  processes  in  demonstration/validation  (DEMA^AL),  engineering  and  manufac¬ 
turing  development  (EMD),  and  modification  and  upgrade  programs. 

Industrial  liaison  to  support  these  activities  can  be  established  through  existing 
organizations  that  have  demonstrated  concern  for  and  understanding  of  the  issues.  They 
should  be  used  to  identify  inhibitors  to  integration  in  fundamental  DoD  and  Service  policies 
and  to  suggest  different  approaches  that  can  realistically  be  expected  to  be  adopted  by 
industry.  Example  organizations  that  could  be  used  include  the  Defense  Industry  Afford¬ 
ability  task  force  of  the  National  Center  for  Advanced  Technologies  (NCAT),  the  CALS 
Industry  Steering  Group,  and  the  Industry  Forum  for  Agile  Manufacturing. 
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2.  Informed  Customers  and  Suppliers 

DoD  and  the  Services  should  integrate  deliverables  within  both  acquisition  and 
technology  programs,  creating  incentives  to  motivate  industrial  process  and 
information  system  integration. 

As  part  of  their  enteiprise  integration  efforts,  DoD  and  the  Services  should  charter 
process  re-engineering  task  forces  to  develop  new  interfaces  and  deliverables  for  Defense 
acquisition  and  technology  programs.  The  new  interfaces  and  deliverables  should  specifi¬ 
cally  motivate  industry  integration  of  its  processes  and  supporting  information  systems. 
Past  experience  in  government  and  industry  has  shown  that  these  efforts  must  be  led  by  the 
line  managers  who  control  and  are  responsible  for  the  processes  in  question.  The  re-engi¬ 
neering  efforts  can  be  facilitated  by  such  organizations  as  CALS  and  the  OSD  Functional 
Process  Improvement  Office  (under  the  auspices  of  the  Assistant  Secretary  of  Defense 
(C^I)  and  the  Deputy  Assistant  Secretary  of  Defense  (Information  Management)),  and  they 
must  be  visibly  supported  and  demanded  by  top  management,  but  the  line-management 
process  owners  must  actually  be  responsible  tuid  authorized  to  execute  the  re-engineering. 

The  separate  functional  or  “stovepipe”  requirements  currently  typical  for  contrac¬ 
tual  deliverables  act  as  inhibitors  to  industry  information  system  and  process  integration 
and  would  inhibit  Defense  use  of  well-integrated  civilian  industrial  capabilities.  In  support 
of  the  process  integration  efforts  described  above,  the  efforts  started  by  the  DoD  CALS  pro¬ 
gram  to  define  integrated  weapons  system  data  bases  and  Contractor  Integrated  Technical 
Information  Services  should  be  accelerated  to  replace  current  separate  CDRLs  for  separate 
functional  areas. 
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The  development  of  industrial  integrated  information  systems  should  be  an  evalua¬ 
tion  factor  in  source  selections  and  an  explicitly  allowable  cost  for  internal  R&D  and  imple¬ 
mentation  phases. 

The  Principal  Deputy  Undersecretary  of  Defense  for  Acquisition  (PDUSD(A)), 
with  the  visible  support  of  the  Deputy  Secretary  as  needed,  should  oversee  the  implemen¬ 
tation  of  this  recommendation  by  line  managers  in  the  Service  acquisition  and  technology 
organizations  and  by  the  OSD  and  Service  owners  of  source  selection  and  allowable-cost 
policies. 
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3.  Partnerships 

DoD  technology  organizations,  cooperating  with  other  interested  federal  agen¬ 
cies,  together  with  leading  industrial  firms,  should  establish  partnerships  to 
develop  information  infrastructures  to  support  integrated  industrial  activities. 

DoD  organizations  such  as  ARPA  and  the  MS&T  offices  should  enter  into  strategic 
partnerships  with  the  U.S.  firms,  both  commercial  and  military,  most  advanced  in  imple¬ 
menting  information  systems  for  enterprise  integration,  and  with  other  interested  govern¬ 
ment  organizations  such  as  NIST,  Department  of  Transportation,  and  Department  of 
Energy.  The  objectives  would  be  to  share  experience  on  implementation  approaches,  met¬ 
rics,  test  and  validation,  and,  where  appropriate,  to  share  the  risk  in  technology  develop¬ 
ments.  These  partnerships  should  be  as  free  as  possible  of  federal  acquisition  constraints  so 
as  to  enable  the  participation  of  firms  that  do  not  normally  contract  with  the  government. 
The  partnerships  should  be  built  within  Advanced  Technology  Demonstrations  (ATDs)  and 
MS&T  pilot  programs  executed  in  settings  grounded  by  real  applications.  DoD  should 
evaluate  leading  company-specific  implementations  for  potential  DoD-wide  application 
and  should  then  support  generic  information  technology  developments  by  vendors  so  as  to 
accelerate  availability  of  vendor-supported  products.  The  goal  would  be  to  shorten  lead 
times,  from  feasibility  demonstration  to  commercial  availability  of  products  based  on  de 
facto  and  appropriate  formal  standards,  from  an  estimated  8  to  15  years  at  present  to  2  to  3 
years.  The  FY94  Technology  Reinvestment  Project  (TRP)  should  be  focused  on  support  for 
high-leverage  design  and  manufacturing  technology  efforts.  The  ARPA  Shared  Infrastruc¬ 
ture  Program  could  be  used  to  support  and  coordinate  the  activities  described  in  this  rec¬ 
ommendation. 
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Commercial  firms  rarely  consider  the  opportunity  to  gain  leverage  by  cooperating 
with  government  in  the  development,  demonstration,  and  deployment  of  technologies  that 
would  improve  industrial  processes  and  for  which  the  government  could  provide  an  appro¬ 
priately  neutral  planning  environment.  DoD  and  other  technology  development  agencies, 
however,  are  increasingly  open  to  civilian  and  military  industrial  cooperation  in  planning 
and  developing  the  required  technologies.  Since  government  appears  willing  to  support 
pre-competitive  industrial  cooperation  to  implement  industrial  information  infrastructures, 
industry,  particularly  those  organizations  that  do  not  normally  engage  in  government  con¬ 
tracting,  should  participate  in  government  activities  (such  as  the  TRP  and  its  successors) 
that  can  help  develop  and  deploy  broadly  applicable  and  desirable  technologies.  Industry 
should  also  advise  government  agencies  seeking  to  cooperate  with  industry  on  how  best  to 
structure  government  activities  to  allow  commercial  participation,  eliminating  the  undue 
burdens  of  the  government  acquisition  system. 

4.  Technology  Demonstrations  and  Development 

4.1  DoD  acquisition  and  technology  organizations  should  implement  pro¬ 
grams  that  demonstrate  innovative  concepts  and  information  systems  for 
enterprise  integration. 

Metrics  and  Benchmarks:  DoD  should  plan  for  ATDs  and  pilot  programs  to  develop 
measures  of  effectiveness  for  enterprise  processes  (for  example,  design,  manufacturing, 
purchasing,  partnering)  and  evaluate  these  as  part  of  the  demonstration  phases  of  the  pro¬ 
grams.  This  may  be  the  highest  leverage  area  for  accelerating  implementation  on  a  broad 
scale  if  the  demonstrations  are  done  on  real  products  in  real  development  and  production 
facilities  and  if  schedules  are  reasonably  short  or  well  phased.  To  support  this,  the  DoD 
should  sponsor  a  series  of  efforts  by  contractors,  the  Services,  and  industrial  cooperative 
organizations  to  establish  enterprise  metrics  such  as  cycle  time,  cost,  and  quality;  enterprise 
information  metrics  such  as  information  cost,  response  time,  latency,  and  quality;  and 
benchmarks  with  respect  to  these.  The  Agile  Manufacturing  Sector  Institutes  and  related 
pilot  programs  should  make  this  a  priority  area  and  develop  comprehensive  programs  for 
achievement  of  this  recommendation. 

Single  and  Multiple  Company  integration:  Technology  developers  and  demonstra¬ 
tors  should  attempt  a  balance  between  inter-company  and  intra-company  integration 
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requirements,  using  common  approaches  where  feasible.  This  requires  demonstrations  of 
single  firms  and  teams  of  firms  in  IPPD  environments. 

Small  Business  Integration:  In  view  of  the  role  of  small  suppliers  in  inter-company 
teaming,  special  effort  should  be  made  to  address  small  business  affordability  issues.  The 
Industry  Forum  for  Agile  Manufacturing  is  chartered,  in  part,  to  work  with  DoD  to  address 
information  infrastructure  and  integration  issues  at  the  small  business  level.  It  should  be 
used  as  a  liaison  with  industry  on  this  issue. 

Network  Services  and  Distributed  Products:  DoD  should  conduct  one  or  more  dem¬ 
onstration  programs  to  assess  the  potential  effectiveness  of  network  services  in  accelerating 
multi-enterprise  integration.  This  would  be  an  economic  alternative  or  complement  to 
widespread  acquisition  of  products  based  on  either  interface  standards  or  generic  vendor 
products.  The  demonstrations  could  be  part  of  the  S&T  Thrust  7  infrastructure  program 
(perhaps  the  Agile  Network  demonstrations)  and  would  include  product/process  definition 
and  EDI  services.  Value-added  network  services  for  design  and  manufacturing  would  be  an 
important  element  of  the  Nil. 

Nil  Manufacturing  Services  and  Interfaces:  In  general,  a  plan  is  needed  to  develop 
and  demonstrate  a  family  of  services  and  interfaces  to  support  manufacturing  applications 
of  the  proposed  NIL  ARPA  should  take  the  lead  to  see  that  the  standards,  specifications,  and 
services  required  for  industrial  design  and  manufacturing  applications  of  the  Nil  are  devel¬ 
oped,  demonstrated,  and  financed.  This  effort  should  be  aimed  at  the  further  integration  of 
the  civil  and  military  industrial  bases  through  the  use  of  generically  applicable  building 
blocks,  available  in  the  open  marketplace,  that  will  use  the  underlying  information  super¬ 
highways.  A  prototype  Nil  manufacturing  demonstration  could  be  planned  using  ATD- 
funded  design  and  manufacturing  centers  connected  by  the  existing  Internet. 

42  DDR&E,  ARPA,  and  Service  technology  organizations  should  implement 
an  aggressive  technology  strategy  to  develop  DoD  industrial  information  infra¬ 
structures  and  to  accelerate  emerging  threshold  technologies. 

DoD,  in  concert  with  leading  companies,  should  formulate  an  R&D  strategy  to  cre¬ 
ate  a  new  generation  of  enterprise  architectures,  models,  tools,  and  software  systems,  and 
to  determine  the  potential  for  new  business  operations,  engineering  practices,  and  manu¬ 
facturing  concepts.  To  achieve  potential  functional  and  performance  improvements,  inte¬ 
grators  should  combine  the  leverage  of  several  emerging  threshold  technologies,  such  as 
operational  integration  frameworks,  object-based  and  knowledge-based  product  and  pro- 
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cess  representations,  application-oriented  network  services,  near-term  and  mid-term  solu¬ 
tions  to  database  integration,  and  wide-area  object  brokerage  and  execution. 

The  strategy  should  be  incremental  and  evolutionary,  balanced  more  toward  bot¬ 
tom-up  and  middle-out  tactics  rather  than  top-down  ones,  because  of  the  lack  of  formal  dis¬ 
ciplines  and  the  need  for  continuous  feedback  into  the  govemment/industry  planning 
process.  Such  a  strategy  requires  an  exploratory  attitude  rather  than  one  in  which  a  static, 
monolithic  plan  is  developed  to  drive  all  developments.  It  also  requires  underlying  technol¬ 
ogies  that  are  designed  to  support  evolution. 

Operational  Frameworks:  In  particular,  ARPA  and  the  Service  pilot  programs 
should  establish  an  effort  to  demonstrate  multi-layer  operational  frameworks  for  tool  and 
information  integration.  Each  of  these  operational  frameworks  should  span  a  multi-compa¬ 
ny,  multi-discipline  enterprise.  This  program  should  have  an  objective  of  providing  the 
United  States  with  the  lead  in  these  critical  integration  framework  technologies  into  the 
next  century.  This  technology  program  should  specifically  address  the  needs  for  DoD  and 
its  aerospace  contractors  in  more  effective  management  of  weapon  programs  throughout 
the  life  cycle.  At  the  same  time,  the  integration  frameworks  should  be  developed  so  as  to 
be  applicable,  desirable,  and  transferable  for  use  in  civilian  applications.  To  accomplish  the 
latter,  it  will  be  necessary  to  engage  appropriate  software  vendors  in  each  R&D  effort.  Par¬ 
ticular  attention  will  have  to  be  paid  to  the  relative  immaturity  of  open  integration  (as  com¬ 
pared  to  that  in  electronics  and  software)  within  the  domains  of  mechanical  and 
manufacturing  CAD/CAE. 

Product/Process  Representations:  Evolvable  product  and  process  representations 
should  be  implemented  in  product-specific,  multi-phase  programs  with  a  coordinating 
mechanism  established  by  ARPA  to  derive  and  feed  back  generic  technical  and  architectur¬ 
al  approaches  for  use  in  later  phases.  ARPA  should  review  the  progress  of  the  PDES/STEP 
standardization  process  and  determine  if  additional  efforts  should  be  focused  on  rapid  dem¬ 
onstration  of  approaches  more  advanced  than  those  emerging  from  the  current  process.  If 
so,  ARPA  should  aim  beyond  current  PDES/STEP  activities  by  developing  more  advanced 
prototype  representations  of  products  and  manufacturing  processes  in  the  context  of  ATDs 
and  pilot  programs.  These  advanced  representations  should  enable  representation  of  the 
semantic  content  of  the  data  via  object  classifications,  feature  types,  and  knowledge  repre¬ 
sentations  as  applicable.  The  representations  should  have  sufficient  depth  to  relate  mission 
performance  simulations  to  design  characteristics  and  manufacturing  process  characteris¬ 
tics.  This  product-specific  implementation  approach  allows  the  representations  to  be  devel- 
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oped  independently,  encouraging  rapid  innovation.  These  advanced  developments  should 
be  part  of  programs  and  projects  that  are  developing  new  approaches  to  IPPD  for  the  spe¬ 
cific  product  classes.  These  independent  representation  developments  should,  however,  be 
coordinated  with  respect  to  technical  strategies  so  successful  prototypes  could  be  combined 
into  a  larger,  reasonably  coherent  scheme  of  representations  and  form  part  of  the  operation¬ 
al  integration  frameworks  required  for  enterprise  integration. 

Advanced  Services:  In  addition  to  delivered-software  solutions,  some  integration 
applications  might  best  be  executed  as  services  on  an  easily  accessible  network.  This 
allows  for  experts  to  guide  execution,  for  access  to  unusual  execution  environments  that 
might  not  be  widely  affordable,  and  for  new  business  and  management  approaches  to  con¬ 
trol  of  the  software  itself. 

Legacy  Database  Integration:  The  challenge  of  legacy  databases  is  very  real  in 
industry  and  will  require  workable  near-term  solutions  such  as  semi-automatic  wrapper 
generation  as  well  as  exploratory  demonstrations  of  mid-  and  long-term  solutions  such  as 
mediation  and  easy-to-tailor  artificially  intelligent  agents.  The  ARPA  Intelligent  Integra¬ 
tion  of  Information  program  is  begiruiing  to  address  these  issues.  This  program  should  be 
expanded  to  cover  a  wider  range  of  application  demonstrations  and  exploration  of  more 
technological  approaches. 

Persistent  Object  Brokerage:  In  addition,  ARPA  should  support  recent  industry 
efforts  on  persistent  object  brokerage  (e.g.,  C!ORBA — Conunon  Object  Request  Broker 
Architecture)  and  their  extension  to  wide-area  applications  so  that  wide-area  enterprises 
can  be  more  easily  integrated. 

43  DoD  technology  organizations  should  take  advantage  of  existing  programs 
and  industry  cooperative  efforts  where  appropriate. 

Even  though  this  study  focused  on  industry  rather  than  government  programs,  sev¬ 
eral  programs  exist  with  potential  to  evolve  industrial  information  infrastructures  for  inte¬ 
gration.  The  topic  of  information  infrastructures  is  expected  to  be  a  significant  part  of  the 
Technology  Reinvestment  Project  (TRP).  Selection  and  management  of  TRP  programs 
should  follow  the  overall  strategy  outlined  here.  Because  of  the  high  leverage  of  infrastruc¬ 
ture  to  U.S.  design  and  manufacturing,  the  follow-on  to  the  current  TRP  should  include  a 
focused  dual-use  infirastructure  program  supported  jointly  by  ARPA,  the  Departments  of 
Commerce  and  Energy,  the  National  Aeronautics  and  Space  Administration  (NASA),  and 
the  National  Science  Foundation  (NSF).  The  Tlmist  7  infrastructure  program  (along  with 

91 


[ 


the  Agile  Manufacturing  Program)  could  provide  the  national  technology  lead.  The  Thrust 
7  ATDs  should  provide  a  demonstration  test  bed  for  intercompany  integration  focused  on 
effective  IPPD.  A  Thrust  7  ATD  plan  should  be  developed  to  implement  this  unique  com¬ 
bination  of  IPPD  test-beds  and  infrastructures. 

Where  applicable,  planners,  developers,  and  demonstrators  should  use  forward- 
thinking,  existing  and  emerging  industry  cooperative  efforts  to  accomplish  required  indus¬ 
try  liaison.  This  in:q}lies  an  understanding  of  the  mechanisms  and  interests  of  various  types 
of  groups  such  as  technology  cooperatives  (for  example,  the  CAD  Framework  Initiative), 
industry-government  cooperatives  (such  as  the  CALS  Industry  Steering  Group),  and  for¬ 
mal  standardization  mechanisms  (such  as  the  ESPRIT  AMICE  consortium,  the  Object 
Management  Group  (OMG),  the  ISO  STEP  conunittees,  and  the  sector-specific  Automo¬ 
tive  Industry  Action  Group). 
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APPENDIX  A.  GENERAL  FINDINGS  AND  ISSUES 


The  companies  visited  reported  two  major  kinds  of  findings.  The  first  kind  includes 
results  that  the  studied  companies  are  getting  from  integration  activities  supported  by  infor¬ 
mation  infirastructures.  These  are  reported  in  the  main  body  of  this  document.  Section  3.3.2 
on  page  59.  The  second  kind  consists  of  general,  non-quantitative  findings  about  the  intent, 
extent,  and  structure  of  integration  activities  and  their  supporting  information  infrastruc¬ 
tures.  These  findings,  presented  in  Section  A.l,  are  organized  according  to  the  same  cate¬ 
gories  as  described  in  Section  1.4  on  page  7. 

^  Many  issues  were  raised  by  the  companies  visited.  Most  of  these  relate  to  differenc¬ 

es  of  scale  between  a  larger  enterprise  and  a  smaller  organization.  An  enterprise  must  inher¬ 
ently  deal  with  more  diversity  than  its  constituent  organizations.  Several  frequently  cited 
issues  are  discussed  in  A.2. 

I  Several  of  the  companies  visited,  especially  but  not  exclusively  defense  contractors, 

mentioned  that  information  protection  and  security  were  important  issues  to  be  considered 
in  integrating  the  information  infrastructure.  In  A.3,  there  is  a  discussion  of  the  issues  and 
the  different  approaches  now  used  to  address  security  risk  management. 

I 

A.1  GENERAL  FINDINGS 

The  findings  of  this  study  are  a  reflection  of  the  current  state  and  trends  of  industry 
efforts  to  integrate.  They  do  not  capture  the  state  of  the  art  from  a  research  or  even  leading 

I  edge  point  of  view,  but  rather  describe  the  progress  that  is  being  made  in  the  companies 

addressing  integration  issues.  These  findings  are  organized  according  to  the  same  catego¬ 
ries  as  described  in  Section  1.4  on  page  7. 

I 
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A.  1.1  SCOPE  OF  ENTERPRISE  INTEGRATION 


a.  Companies  are  making  significant  commitments  and  executing  large  efforts  in 
the  direction  of  enterprise  integration.  Significant  results  are  being  achieved,* 
but  companies  now  recognize  that  achieving  significantly  more  is  feasible. 

b.  The  notion  of  “enterprise”  is  recognized  as  encompassing  supplier  relationships 
(that  is,  the  “enterprise”  is  the  value  chain  that  results  in  a  distributed  aud  mar¬ 
keted  product),  but  the  current  implementation  of  enterprise  integration  is 
largely  within  companies  or  large  divisions.  There  are  exceptions  in  all  three  sec¬ 
tors,  notably  in  aircraft  projects,  where  this  is  due  to  the  number  of  team 
members  required  to  produce  the  large,  complex  product. 

c.  The  notion  of  “integration”  has  several  dimensions,  each  a  continuum.  For 
example,  a  company  can  be  integrated  to  a  greater  or  lesser  extent  in  the  sense 
of  passing  design  information  from  the  design  engineering  activity  to  manufac¬ 
turing.  Or  its  design  engineering  and  manufacturing  engineering  activities  can  be 
integrated  to  a  greater  or  lesser  extent.  Or  manufacturing  operations  themselves 
can  be  integrated  more  or  less. 

d.  Enterprise  integration  is  a  way  to  get  groups  of  people  and  their  machines  to 
work  together  toward  a  common  goal.  It  tends  to  decrease  overhead  and  “hidden 
enterprise”  costs,  but  it  is  not  magic.  A  well-integrated  company  can  still  make 
wrong  decisions,  be  affected  by  financial  catastrophe,  and  the  like.  People  who 
implement  integration  feel  that  it  does  make  the  coiTq)any  more  quickly  adapt¬ 
able  to  unforeseen  events.  Integration  is  not  easy  to  implement,  though  largely 
for  cultural-organizational  reasons. 

e.  Change  management  is  a  theme  that  appears  in  most  discussion  of  enterprise 
integration  and  integration  infrastructure.  Ranging  from  very  large  to  highly 
focused,  changes  may  be  ad  hoc  or  permanent.  Information  and  control  flows 
change  both  in  the  human  side  of  the  enterprise  and  the  automated  side,  with  the 
nature  of  the  information  itself  changing.  The  issue  of  “evolvability”  and  tai- 
lorability  is  a  recognized  issue.  Some  companies  have  made  progress  in 
accommodating  change  in  their  information  systems.  The  National  Center  for 
Manufacturing  Sciences  (NCMS)  project  on  computer-integrated  manufacturing 
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Selected  results  are  summarized  in  Section  2.1.3  on  page  16. 
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(CIM)  has  adopted  the  catch-phrase  “design  for  change”  to  reflect  the  thrust  of 
its  efforts. 


A.1.2  RELATIONSHIPS  AMONG  COMPANIES 

a.  Outsourcing  is  generally  increasing.”  The  reasons  for  outsourcing  include  the 
results  of  cost/capacity  analysis,  quality  of  outsourced  goods  being  better  than 
like  items  internally  produced,  and  increased  internal  focus  on  core  competen¬ 
cies. 

b.  Relationships  between  supplier  and  purchaser  are  being  strengthened.  Purchas¬ 
ers  are  using  fewer  suppliers  and  are  involving  them  more  in  end-product  design 
decisions.^  The  decrease  in  the  number  of  suppliers  is  being  driven  by  the  desire 
to  increase  quality  both  by  decreasing  variability  in  (the  quality  of)  supplied 
items  and  by  developing  longer-term  partnership-like  relationships  with  suppli¬ 
ers.  These  partnerships  are  perceived  as  allowing  greater  integration  of  suppliers 
into  the  companies’  processes.  This  trend  was  reported  in  many  of  the  companies 
visited. 

c.  Subsystem,  engineering,  and  manufacturing  suppliers  envision  the  benefit  of 
generic  information  infrastructure  solutions,  as  relieving  the  suppliers  from 
acquiring  and  maintaining  multiple  systems  to  satisfy  multiple  customers.'^ 

d.  Most  integration  among  companies  is  hierarchical  in  that  one  company  domi¬ 
nates  the  integration  culture.  The  dominant  company  might  be  a  major  customer 
imposing  its  internal  infrastructure  on  its  suppliers,  or  it  might  be  a  prime  con¬ 
tractor  mandating  the  program’s  infrastructure  to  team  members. 

e.  Prime  contractor  teaming  puts  prime  contractors  in  the  same  position  as  first-tier 
suppliers  in  the  automotive  industry:  they  must  be  prepared  to  use  computer- 
aided  design  (CAD)  systems  that  satisfy  several  different  lead  contractors.  The 
nature  of  the  negotiation  on  what  systems  to  use  on  a  given  program,  though,  is 
a  negotiation  among  more-or-less  equals.  The  absence  of  standard  data  inter¬ 
faces  in  this  case  results  in  higher  costs  to  the  government. 


^  Overcapacity  is  causing  some  reversal  of  the  outsourcing  trend  in  some  companies  studied. 

^  The  decrease  in  suppliers  can  be  quite  pronounced.  For  example.  Xerox  has  decreased  its  number  of  sup¬ 
pliers  by  at  least  a  factor  of  twelve  in  a  decade. 

'*  For  example.  Modem  Engineering  maintains  16  different  types  of  CAD  systems  to  satisfy  auto  industry 
customers.  This  has  costs,  such  as  personnel  inefficiency,  beyond  the  CAD-system  costs. 
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f.  DoD’s  integration  with  its  contractors  is  characterized  to  date  almost  exclusively 
as  interfacing  via  batched  delivery  of  information  one  way  or  the  other.  ^  Infor¬ 
mation  is  not  shared  on  a  continuous  basis  during  a  project.  Many  program 
offices  do  not  possess  the  infrastructure  elements  required  to  integrate  with  will¬ 
ing  contractors.  Some  companies  are  concerned  that  the  DoD  cannot  become 
more  integrated  with  contractor  activities  without  becoming  intrusive. 

g.  Electronic  data  interchange  (EDI),  based  on  initial  available  standards  and  ser¬ 
vices,  is  being  used  increasingly  for  supplier  business  transactions.  Outside  EDI 
services  provide  translations  of  some  data. 

A.1  J  RELATIONSHIPS  WITHIN  COMPANIES 

a.  In  many  companies  management  has  succeeded  in  exerting  the  leadership 
required  to  integrate  activities  and  information  across  independent  entities. 

b.  The  baseline  organizational  structures  to  which  integration  has  been  successfully 
applied  varies  considerably  among  companies. 

c.  Management  of  change  is  a  critical  problem  for  all  companies  studied.  There  are 
many  notions  of  “change”  with  which  people  are  concerned. 

d.  There  is  a  trend  in  industry  to  try  to  increase  efficiency  by  reducing  the  number 

of  layers  of  management  Some  high-level  managers  see  information  integration  ' 

as  enabling  a  reduction  in  management  structure.^  Conversely,  some  see  the 
downsizing  of  management  as  enabling  integration  through  the  elimination  of 
empires 

e.  (^ality  was  used  explicitly  to  justify  enterprise  integration  projects  in  only  a  few  ^ 

companies.  The  companies  in  this  study  that  have  strong  quality  programs  view 

enterprise  integration  as  a  required  step  after  concurrent  engineering  is  adopted. 

A.1.4  ROLES,  OBJECTIVES,  AND  PRACTICES  OF  INFORMATION  INFRA-  ( 

STRUCTURES 

a.  Information  sharing  and  flow  (key  aspects  of  “information  management”)  are 
recognized  as  critical  ingredients  of  enterprise  integration. 

*  A  notable  exception  is  the  F-22  program,  where  the  SPO  (subsystem  project  office)  is  also  co-located  with  * 

Lockheed. 

^  Some  futuristic  thinkos  take  the  notion  of  information-system-assisted  management  further.  There  is  a 
possibility,  based  on  trends  and  the  literature,  that  traditional  hierarchical  and  matrix  management  struc¬ 
tures  will  mutate  into  more  dynamic  arrangements.  These  dynamic  arrangements  would  be  based  on 
projects  that  respond  to  market  developments.  f 
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b.  Information  management,  while  critical,  is  viewed  as  dominated  by  cultural  and 
organizational  issues. 

c.  Most  implementers  regard  assistance  with  change  management  as  a  key  goal  of 
information  integration. 

d.  When  error  rates  are  analyzed  and  hidden  costs  considered,  the  argument  for 
paperless  systems  is  compelling  to  the  companies  studied.  Therefore,  they  tend 
not  to  perform  traditional  cost-benefit  analyses  on  this  issue.  One  major  barrier 
to  paperless  systems  is  the  lack  of  capital  to  invest  in  new  systems.  Even  when 
systems  are  intended  to  be  paperless,  most  implementations  are  not  entirely  so 
due  to  the  absence  of  a  legally  binding  digital  signature  technology.^ 

e.  Companies  must  deal  with  legacy  systems  in  their  integration  plans.  One  reason, 
among  many,  is  that  the  companies  must  maintain  certain  data  beyond  the 
expected  life  of  the  tools  and  systems  in  which  the  data  resides.  Thus,  even  a 
clean  start  must  plan  for  evolvability.  Several  approaches  being  used  are 
described  in  Section  2.2.2  on  page  31. 

f.  Object-oriented  technology  is  being  increasingly  used  to  implement  the  encap¬ 
sulation  of  legacy  systems  and  other  integration  paradigms. 

g.  Information  modeling  and  process  modeling  are  being  used  in  some  companies 
for  various  reasons  such  as  redesigning  white-collar  processes  for  efficiency, 
identifying  redundant  information,  training,  and  determining  information  inte¬ 
gration  priorities. 

A.l^  ARCHITECTURE  OF  INTEGRATED  INFORMATION  INFRASTRUC¬ 
TURES 

a.  In  the  absence  of  genetically  applicable,  widely  accepted  interface  and  data 
exchange  standards,  most  companies  are  adopting  a  common-systems  approach 
to  integration  within  increasingly  larger  islands  of  automation.  This  approach  is 
consistent  with  the  current  CAD  industry  consolidation  (which  has  many 
causes).  This  consolidation  is  resulting  in  a  relatively  small  number  of  widely 
used,  major  CAD  systems  in  each  CAD  domain  (electrical,  mechanical,  soft- 


^  This  appears  to  be  a  legal  issue,  not  a  technical  one. 
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ware*).  There  are  many  niche  tool  vendors;  they  currently  tend  to  force  users  to 
make  the  effort  to  interface  or  integrate  with  the  larger  systems. 

b.  Although  an  infoimation  system  supportive  of  integration  need  not  use  publicly 
available  or  standard  interfaces,  it  must  have  a  stable  and  well-understood  archi¬ 
tecture  for  interoperability. 

c.  The  level  of  interoperability  required  depends  on  usage  patterns  of  the  applica¬ 
tions  and  systems  in  question. 

d.  In  the  computer-aided  software  engineering  (CASE)  domain,  there  are  efforts  to 
implement  integrated  information  systems  that  use  models  to  organize  informa¬ 
tion  and  to  assist  in  activity  management  and  policy  enforcement.  The  idea  here 
is  to  make  the  system  behavior  easy  to  tailor  and  change. 

e.  Most  of  the  companies  studied  are  implementing  a  “continents  of  integration  and 
automation’’  strategy  to  support  integration  goals.  This  means  that  they  are  mov¬ 
ing  from  very  large  numbers  of  loosely  coupled  activities  and  disconnected 
information  systems  (“islands  of  automation’’)  to  a  small  number  of  “conti¬ 
nents.” 

f.  The  current  state  of  most  companies  is  that  their  information  infrastructures 
include  a  heterogeneous  assortment  of  computers,  software,  and  communica¬ 
tions  networks.  On  the  manufacturing  flow  at  the  level  of  the  individual 
workcells,  the  configuration  of  hardware  and  software  is  among  the  worst  in  the 
enterprise.  This  is  particularly  visible  by  contrast  with  what  has  been  accom¬ 
plished  at  NeXT  Computers,  which  has  used  its  own  workstations  at  each 
manufacturing  cell  and  has  thereby  created  a  common  interface  across  the  com¬ 
pany. 

A.1.6  ROLE  OF  STANDARDS  IN  INTEGRATED  INFORMATION  INFRA¬ 
STRUCTURES 

a.  A  widespread  desire  for  widely  accepted  information  standards  exists  in  the 
companies  visited.  If  the  demand  for  standards  were  articulated  with  sufficient 
focus,  strength,  and  indication  of  priorities,  a  focused  response  from  the  vendors 
would  be  elicited.  Only  a  few  companies  prefer  to  rely  on  internally  created  sys- 


^  The  consolidation  is  somewhat  less  evident  in  the  software  domain  so  far.  In  the  software  engineering 
(computer-aided  software  engineering  or  CASE)  domain,  there  is  a  correspondingly  greater  level  of  effon 
to  standardize  interfaces. 
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terns  with  company-specific  data  representations  as  a  matter  of  strategic  advan¬ 
tage;  these  companies  have  relatively  less  interest  in  standards.  It  appears  that  in 
most  cases,  vendors  also  have  an  interest  in  widely  accepted  standards  and 
would  prefer  their  existence  ^ 

b.  Most  companies  who  use  EDI  do  so  through  value-added  EDI  services,  which 
interface,  or  translate,  among  various  EDI  implementations.  This  reflects  com¬ 
mon  shortcomings  standards  with  respect  to  integration  requirements.  Some 
standards  express  the  least  common  denominator  of  competing  technologies  and 
are  extended  when  implemented  into  products,  often  in  incompatible  ways. 
Other  times,  the  integration  of  similar  products  is  impeded  because  the  manufac¬ 
turers  use  different,  incompatible  standards  for  the  same  information. 

c.  One  can  standardize  on  technologies,  information  models,  interchange  formats, 
procedural  interfaces  (e.g..  Application  Program  Interfaces  (APIs)),  and  so  forth. 
Standardization  of  interfaces  facilitates  integration  much  more  than  standardiza¬ 
tion  of  technologies  or  formats.  Standards  bodies  should  focus  on  the 
maintaining  the  integrity  of  their  products  (standards). 

d.  There  is  a  natural  tendency  observed  in  standardization  efforts  to  concentrate  on 
bottom-up  interests  according  to  what  is  comfortable  to  the  volunteer  partici¬ 
pants.  This  is  a  behavior  observed  in  the  actual  working  groups  and  may  be  quite 
independent  of  the  publicly  stated  goals  of  the  effort.  Efforts  carried  forward 
with  full-time  staff  support  more  quickly  accontplish  their  goals. 

e.  The  companies  visited  want  more  integrated  infrastructures  both  because  the 
current  infrastructure  is  viewed  as  a  barrier  to  integrated  activities  and  because 
an  integrated  infrastructure  would  facilitate  the  information  sharing  on  which 
integrated  activities  depend.  One  representative  reported  that  for  every  CAD/ 
CAE  dollar  his  company  spends,  it  spent  $1.50  trying  to  get  the  systems  to  work 
together  to  support  integrated  activities. 

A.  1.7  STATE  OF  TECHNICAL  UNDERSTANDING  OF  HOW  TO  ENGINEER 
INTEGRATED  INFORMATION  SYSTEMS 

Progress  is  being  made  in  integrating  systems.  The  understanding  of  engineering 
issues  inherent  in  such  systems  could  use  improvement.  This  understanding  is  likely  to 


^  Not  many  CAD/CAM  vendors  were  interviewed  for  this  study.  The  statement  of  vendor  interest  is  based 
on  an  insider  view  of  vendor  activities  within  the  CAD  Framework  Initiative. 
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increase  through  continued  industrial  efforts,  through  demonstrations  of  new  approaches  in 
realistic  settings,  and  through  directed  research  and  development  of  new  integration  prod- 
ucts.  The  following  findings  focus  on  issues  that  surfaced  in  the  implementations  reviewed 
for  this  study. 

a.  Understanding  of  how  to  represent  products  and  their  related  processes  for  effi- 
cient  use  in  automated  systems  varies  considerably  across  product  types.  Very 
little  effort  was  found  in  the  area  of  representing  management  policies  for  use  in 
automated  systems. 

b.  Leading  user  companies  are  just  beginning  to  discover  how  to  use  available  tech¬ 
nology  to  design  the  information  infrastructure  for  evolution.  Vendors  aie 
beginning  to  supply  systems  supportive  of  evolution. 

c.  There  is  a  need  in  user  companies,  information  system  vendors,  and  the  research 
community  to  provide  a  basis  for  system  engineering  by  improving  the  under¬ 
standing  of  relationships  among  openness,  integration,  performance  of 
information  systems,  and  performance  of  end-user  processes.^®  Such  an  under¬ 
standing  could  assist  in  counteracting  die  tendency  of  integradon  implementers 
to  concentrate  on  local  optimizations  (for  example,  by  creating  larger  islands  of 
automation)  rather  than  on  what  is  globally  required  by  the  enterprise. 

d.  Part  of  the  integrated  system  engineering  problem  is  the  absence  of  widely 
accepted  measures  of  progress.  There  is  also  a  cultural  barrier  to  the  use  of  met¬ 
rics,  especially  in  highly  integrated  information  systems.  Middle  managers  are 
concerned  that  increased  upper  management  visibility  into  day-to-day  activities 
will  be  counterproductive. 

e.  For  success  a  high-level  sponsor  is  critical  to  the  task.  The  sponsor,  typically  a 
president  or  a  vice-president,  needed  to  be  in  the  common  chain  of  command  so 
that  this  one  person  could  resolve  impasses  between  groups  and  smooth  manage¬ 
ment  delays  that  occurred  between  the  project  management  level  and  the 
sponsor's  level.  This  sponsor  tends  to  be  the  Least  Common  Manager  above  the 
groups  to  be  integrated.  Only  very  strong,  constant,  and  visible  top  leadership 
can  overcome  the  typically  encountered  cultural  barriers. 


This  thought  is  a  slight  variation  on  a  suggestion  by  George  Heilmeier  and  is  borne  out  by  the  observations 
in  this  study. 
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A.2  ISSUES 

A  number  of  issues  were  raised  by  several  of  the  companies  visited,  reflecting  prob¬ 
lematic  cost-benefit  trade-offs,  needs  for  new  research  and  its  application,  or  needs  for  new 
policies  and  operating  procedures. 

a.  Balance  between  integration  and  divisional  independence.  In  a  situation  where 
autonomous  divisions  of  the  same  company  pursue  integration  independently,  it 
is  hard  to  achieve  a  consistent  approach  to  integration,  and  there  is  duplication 
of  effort  and  learning  in  the  various  divisions.  Localized  integration  improve¬ 
ments  are  very  important  and  worthwhile,  but  the  really  impressive  savings 
remain  largely  unrecognized  because  the  result  only  from  improvement  of  the 
larger  [corporate-wide]  “systems.”  Management  is  balancing  between  the  costs 
and  benefits  of  independence.  A  corporate  information  systems  organization 
helping  to  integrate  a  division  or  divisions  may  have  goals  or  approaches  to  inte¬ 
gration  that  conflict  with  those  of  the  divisions. 

b.  Drawbacks  of  the  “continents  of  integration”  approach.  The  “continents  of  inte¬ 
gration”  must  be  seen  as  a  commonly  used,  evolving  approach  to  integration. 
However  it  has  three  potential  drawbacks,  based  on  investment,  consistency,  and 
evolvability.  A  large  investment  in  an  “island”  may  create  an  inertia  barrier 
against  future  integration,  since  required  change  may  be  seen  as  devaluing  the 
original  investment  Coordinating  integration  efforts  across  large  companies  to 
ensure  a  consistent  evolvable  approach  to  integration  is  difficult.  Without  pro¬ 
viding  for  evolvability,  separate  “islands”  may  adopt  incompatible  infrastructure 
mechanisms,  thereby  incurring  either  re-implementation  costs  or  increased  sys¬ 
tem  maintenance  costs. 

c.  User  acceptance  of  direction  bv  process  models.  A  process  model  can  be  the 
basic  data  structure  for  establishing  a  set  of  operational  procedures  guided  or 
enforced  by  the  information  infrastructure  to  establish  work  procedures.  If  an 
enterprise  so  desired,  a  worker  would  see  the  process  steps  for  some  activity  on 
a  screen  and  indicate  what  he  wanted  to  do  next.  The  information  system  could 
determine  from  the  model  and  the  current  state  of  the  enterprise  whether  such  a 
step  were  allowed.  Several  companies  voiced  concern  about  the  willingness  of 
workers,  particularly  engineers,  to  use  such  a  system. 

d.  Modeling  and  managing  the  meaning  of  information.  If  all  the  information  man¬ 
aged  by  the  information  infrastructure  were  contained  in  a  machine-sensible 
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information  model,  there  would  be  a  greater  chance  that  the  meaning  of  the 
information  could  be  conveyed  by  the  infrastructure  over  great  distances  in  both 
space  and  time.  However,  the  capture  of  meaning  for  use  by  computers  is  at  once 
an  available  technology  and  a  research  issue. 

e.  Policies  and  support  for  information  integrity.  Current  implementations  of  tech¬ 
nical  protection  have  focused  on  preserving  confidentiality  of  information  and 
have  been  aimed  primarily  at  supporting  DoD  requirements.  A  much  broader  set 
of  protection  policy  issues,  such  as  authority,  update  integrity,  and  self-protec- 
tion  (error  avoidance),  remain  ignored  and  their  implementation  or  support  in 
computer  systems  continues  to  be  a  research  issue. 

A.3  SECURITY  RISK  MANAGEMENT  AND  INTEGRATED  ENTERPRISE 
INFORMATION  PROTECTION 

Integration  of  enterprise  information  is  currently  taking  place  within  many  compa¬ 
nies  along  functional  lines  (e.g.,  engineering,  finance,  manufacturing)  and  will  provide 
“large  islands”  of  processing  in  logically  centralized,  possibly  widely  distributed,  function¬ 
al  centers.  For  many  companies,  the  next  step  is  to  integrate  across  functional  lines  begin¬ 
ning  with  key  functions  such  as  engineering  and  manufacturing,  manufacturing  and 
finance,  etc.  Further  integration  to  include  suppliers  and  customers  is  envisioned  by  most 
companies  and  may  occur  before  cross-functional  integration.  These  integration  steps  need 
to  be  assessed  in  terms  of  security  risk  and  information  protection.  Specific  risk  manage¬ 
ment  approaches  need  to  be  negotiated  and  defined  so  that  they  are  suitable  to  the  environ¬ 
ment  each  participant  brings  to  the  “integration  table.” 

There  are  three  major  approaches  available  to  address  and  manage  risks  to  informa¬ 
tion  assets  or  to  assets  represented  by  information  in  automated  information  systems:  legal 
redress,  insurance,  and  the  incorporation  of  self-protection  via  various  security  measures. 
All  three  must  be  considered  in  assessing  the  trade-off  issues  of  managing  both  unique 
company-oriented  and  general  inherent  risks  in  the  integration  of  enterprise  information. 

A.3.1  LEGAL  REDRESS 

Legal  redress  protects  against  patent  and  copyright  infringement,  provides  both  a 
deterrent  factor  and  retribution  against  fraud,  trade  secret  theft,  or  other  criminal  exploita¬ 
tion,  and  provides  for  potential  restoration  of  actual  losses  plus  compensation  in  some  cases 
in  the  form  of  punitive  damages.  This  form  of  risk  protection  has  served  industry  well  to 
date;  however,  the  legal  models  suited  for  manually  supported  or  semi-automated  informa- 


tion  systems  are  not  necessarily  suited  for  fully  integrated  automated  enterprise  informa¬ 
tion  systems.  The  need  for  review  of  legal  models  with  respect  to  information  security  and 
intellectual  property  rights  in  computer  systems  is  vital.  The  most  central  issue  involves  the 
determination  of  accountability  of  actions  (the  binding  of  evidence  of  scope  of  actions  of 
individuals  to  assigned  responsibilities  and  authority)  within  an  automated  information  sys¬ 
tem,  and  whether  “due  care”  has  been  taken  in  establishing  controls  to  manage  risk.  Laws 
dealing  with  a  variety  of  intellectual  property  rights  issues  and  information  security  in  com¬ 
puter  systems  are  either  non-existent,  still  in  the  issue  analysis  and/or  law  formulation 
stage,  non-enforceable,  or  untried.  The  unwillingness  of  industry  to  report  offenses  or  to 
prosecute  offenders  has  been  a  major  contributing  factor  to  the  inability  to  get  these  laws 
formulated,  enforced,  or  assessed.  As  electronic  commerce  expands  along  with  enterprise 
integration,  this  aspect  of  risk  management  must  be  revisited  and  made  effective  for  the 
new  environment. 

A.3,2  INSURANCE 

Insurance  has  two  forms.  The  first  protects  against  actual  loss  of  assets  based  on  a 
premium  payment  for  risk  coverage  per  unit  of  time.  In  this  case,  insurance  is  the  contin¬ 
gent  replacement  of  asset  value  and  not  necessarily  the  replacement  of  the  asset.  Thus,  the 
complete  loss  of  information  vital  to  a  con:q)any’s  survival  might  not  be  replaceable.  It  is, 
in  reality,  risk  management’s  solution  of  last  resort  This  fact  promotes  the  second  form  of 
insurance,  which  is  contingent  redundancy  or  fault  tolerance.  In  this  case,  the  vital  infor¬ 
mation  assets,  and  perhaps  the  processing  resources,  are  backed  up  in  another  location 
where  they  are  able  to  be  used  to  meet  the  contingency  of  loss  of  the  primary  information 
or  processing  resources.  The  key  to  viability  of  die  second  form  of  insurance  is  not  just  a 
contingency  plan,  but  rather  the  actual  periodic  exercise  of  the  contingency  to  ensure  cur¬ 
rency  of  preparation  and  awareness  of  potentially  degraded  response.  Single  point  failures 
should  be  examined  closely.  Assessment  of  availability  (e.g.,  timing  constraints  and  allow¬ 
able  degradations  in  response  to  requests  for  resources  or  information)  must  be  made; 
appropriate  policies  must  be  established  and  implemented.  Insurance  approaches  are  an 
overhead  burden  that  must  be  accepted  as  the  only  way  to  address  many  of  the  risks  inher¬ 
ent  in  enterprise  information  integration. 

A.33  SECURITY  MEASURES 

The  third  approach  to  managing  risks  involves  the  incorporation  of  physical, 
administrative,  and  technical  security  measures  to  protect  both  the  information  asset  and 
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the  assets  represented  by  the  information  (e.g.,  actual  parts  inventories,  monetary  assets, 
proprietary  processes).  Physical  security  involves  providing  guards,  sensors,  and  barriers 
to  isolate  sensitive  areas  and  to  control  and  monitor  access  in  and  out  of  these  areas.  Admin¬ 
istrative  security  includes  personnel  screening  and  procedural  controls  and  monitoring  of 
individuals  performing  their  assigned  duties.  Technical  security,  which  is  the  primary  focus 
of  the  remainder  of  this  section,  is  the  implementation  of  controls  and  the  monitoring  of 
actions  conducted  within  the  computer  system. 

Technical  security  addresses  the  hardware,  operating  system,  networks,  databases, 
and  applications  that  compose  the  integrated  enterprise’s  automated  information  system. 
As  one  begins  to  integrate  functions  through  automated  information  systems,  more  and 
more  of  the  mostly  manual  administrative  and  physical  security  controls  used  in  companies 
today  must  be  migrated  into  the  computer  system  so  that  protection  policies  can  continue 
to  be  enforced.  The  normal  space  and  time  gaps  associated  with  paper-oriented  manual  and 
semi-automated  protection  processes  will  no  longer  exist  This  aspect  of  protection 
becomes  more  important  as  the  degree  of  enterprise  integration  increases  to  one  of  a  paper¬ 
less,  electronic  commerce  environment 

Technical  security  in  automated  information  systems  is  typically  discussed  in  terms 
of  three  general  policies:  confidentiality,  integrity,  and  availability.  Key  aspects  of  these 
three  policies  are  highlighted  below. 

a.  Confidentialitv  policies.  What  information  is  to  be  protected  from  disclosure 
(e.g.,  proprietary  processes,  personnel  information,  strategic  planning  informa¬ 
tion,  proprietary  designs)?  Who  authorizes  disclosure?  How  is  this  protected 
information  identified?  Wfio  changes  protection  requirements?  Key  aspects  of 
these  policies  include  confidential  information  access  control,  delegation  of 
authority,  security  administration,  distribution  control,  information  marking, 
auditing,  and  enforcement  monitoring. 

b.  Integrity  policies.  An  overall  integrity  policy  can  be  broken  down  into  separation 
policies,  sharing  policies,  and  self-protection  policies. 

( 1 )  Separation  policies.  How  will  organizational  roles  and  duties  be  reflected  in 
the  system?  Who  is  allowed  to  execute  a  particular  duty  or  process?  Who  is 
responsible  for  delegation  of  authority?  How  are  responsibilities  that 
require  separation  to  be  handled?  How  is  the  individual  accountability  for 
their  actions  to  be  handled?  Key  aspects  of  these  policies  include  account¬ 
ability',  identification  and  authentication  of  both  individuals  and  informa- 
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tion,  encapsulation  of  the  scope  of  authority,  execution  access  control, 
software  importation,  network  access,  information  marking,  internal  control 
systems,  and  systems  administration. 

(2)  Sharing  policies.  What  information  is  to  be  shared?  Who  is  responsible  for 
the  quality  and  reliability  of  the  information?  How  is  the  quality  to  be 
assessed  and  protected?  Key  aspects  of  these  policies  include  configuration 
management  and  version  control,  shared  information  access  control,  attribu¬ 
tion  and  accountability  of  change,  information  process  reliability  and  qual¬ 
ity  control,  application  reliability,  and  quality  control. 

(3)  Self-protection  policies.  How  will  individual  users  be  protected  from  doing 
accidental  (or  perhaps  intentional)  harm  to  their  work  products?  How  toler¬ 
ant  should  the  user  interface  management  system  (UIMS)  be?  Should  the 
potential  action  be  validated  prior  to  committing  or  should  error  messages 
be  returned  at  the  time  of  commit?  Should  there  be  a  universal  “undo”  capa¬ 
bility?  How  should  the  use  of  that  capability  be  monitored?  Key  aspects  of 
these  policies  include  UIMS  design,  identification  and  authentication,  error 
specification  and  detection,  fault  tolerance  and  error  recovery,  and  auditing. 

c.  Availability  policies.  What  are  the  response  times  required  for  information  or 
resources  to  be  available?  What  are  the  sources  of  competition  for  services  or 
information?  What  internal  agreements  must  be  specified  to  ensure  response 
times  are  met?  What  are  acceptable  modes  of  degraded  operations?  Key  aspects 
of  these  policies  include  single  point  of  failure  analysis,  system  fault  tolerance, 
resource-  and/or  iirformation-demand  management,  network  management,  and 
real-time  system  requirements. 

Current  implementations  of  technical  protection  have  focused  on  preserving  confi¬ 
dentiality  of  information  and  have  been  aimed  primarily  at  supporting  DoD  requirements. 
A  much  broader  set  of  protection  policy  issues,  as  indicated  above,  remain  relatively 
ignored,  and  the  possibilities  of  their  efficient  and  near-term  implementation  or  implemen¬ 
tation  support  in  computer  systems  continue  to  be  research  questions. 

Other  issues  that  are  associated  with  physical  and  technical  protection  include  con¬ 
fining  information,  security  in  large  database  systems,  storage  media,  the  “insider”  threat, 
and  expressing  protection  policy  requirements. 

a.  Confining  information.  Once  information  is  made  available  on  a  system  in  a 
sharing  mode,  how  is  it  to  be  confined  to  remain  within  a  cluster  of  workstations 


if  these  workstations  are  part  of  a  large  distributed  network  of  mainframes,  sys¬ 
tem  servers,  and  individually  shared  workstations,  all  supporting  integration? 
Physical  gaps  in  certain  networks  may  be  a  required  part  of  the  near-term  solu¬ 
tion. 

b.  Security  in  large  database  systems.  This  issue  remains  a  research  question.  Some 
of  the  issues  of  confidentiality  in  database  management  systems  are  just  now 
being  addressed.  Research  prototypes  and  early  attempts  at  production  systems 
are  emerging.  Integrity  and  availability,  to  some  extent,  have  been  explored  since 
the  beginning  of  database  technology,  but  new  understandings  of  the  issues  have 
led  to  the  need  for  additional  research.  Transaction  volumes  and  performance 
requirements  in  large  database  systems  mandate  reduced  overhead  in  security 
monitoring  controls.  The  concepts  embodied  in  object-oriented  approaches  indi¬ 
cate  some  promise  to  improving  security,  and,  more  particularly,  to  reducing 
security  overhead  if  implemented  in  a  vertically  partitioned  system.  However, 
object-oriented  approaches  and  vertically  partitioned  systems  have  not  been 
explored  sufficiently  to  claim  success  objectively. 

c.  Storage  media.  As  technology  becomes  more  capable  of  storing  an  increasing 
density  of  information  on  smaller  storage  media,  two  needs  arise.  The  first  is  the 
greater  need  for  backup  of  stored  information  as  a  contingency  to  media  failure 
or  damage.  The  second  is  the  need  for  new  forms  of  physical  security  to  detect 
the  unauthorized  removal  or  introduction  of  such  media. 

d.  The  “insiderV  threat.  Where  access  to  more  of  a  company’s  information  or  to 
more  asset  control  information  is  potentially  available,  the  “insider”  issue  as  a 
component  of  competitive  risk  may  become  more  significant.  The  insider  is  one 
who  is  trusted  to  have  access  or  possession  of  key  information  or  to  make  key 
decisions.  The  insider  can  be  vulno^able  to  outside  pressures  (e.g.,  money,  extor¬ 
tion)  or  to  internally  generated  pressures  (e.g.,  greed,  retribution)  to  violate  the 
trust  granted  to  him  or  her.  This  trust  violation  may  be  to  disclose,  modify,  dam¬ 
age  or  destroy  information,  or  to  commit  theft  or  fraud  in  the  acquisition  of  assets 
represented  by  information.  It  is  important  that  the  most  trusted  individuals  be 
closely  audited  to  ensure  accountability  of  their  actions.  It  is  also  be  important 
that  they  be  limited  in  their  capabilities  to  act  independently  or  to  assume  privi¬ 
leges  that  enable  them  to  act  as  surrogates  for  subordinates  whose  actions  they 
supervise  and  authorize.  The  insido*  risks  may  not  be  readily  apparent  now,  but 
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they  should  be  closely  examined  prior  to  and  continually  after  implementation 
of  the  enterprise  information  integration  model. 

'  e.  Expressing  protection  policy  requirements.  The  most  difficult  issue  related  to 

technical  security  is  how  to  express  the  protection  policy  requirements  to  the 
community  responsible  for  developing  solutions  so  that  they  can  incorporate 
policy  or  policy  support  into  the  computing  systems.  To  make  integration  effec- 
^  tive,  efficient,  and  acceptably  risk-free  as  we  increase  the  environment  of 

electronic  commerce,  each  participant  should  examine  current  manual  policies 
and  procedures  to  assess  what  risks  they  are  currently  managing  and  how  those 
risks  will  be  transformed  in  the  electronic  environment  This  examination  will 
^  lead  to  the  establishment  of  new  policies  and  procedures  that  must  be  imple- 

mentable  in  or  via  our  computing  systems.  While  some  of  the  more  local  aspects 
of  information  can  occur  now,  more  significant  integration  should  not  occur 
without  a  detailed  examination  of  acceptable  risks  and  the  requirements  for  risk 
^  management  especially  protection  requirements  for  automated  systems. 
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APPENDIX  B.  ELECTRONICS  INDUSTRY  RATIONALE 
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For  the  purposes  of  this  study,  the  manufacturing  industry  was  panitioned  into  three 
sectors:  electronics,  automotive,  and  aerospace. 

•  The  electronics  sector  included  computer  manufacturers,  electronic  compo¬ 
nents  manufacturers,  and  other  companies  whose  products  are  based  on  elec¬ 
tronics  technology  (this  appendix). 

•  The  automotive  sector  is  characterized  as  automobile  and  heavy  -’uipment 
manufacturers,  and  their  suppliers  (Appendix  C). 

•  The  aerospace  sector  is  characterized  as  airframe  and  engine  manufacturers 
(Appendix  D). 

This  chapter  documents  the  state  of  enterprise  integration  as  it  exists  today  in  the 
electronics  industry  sector,  and  creates  a  vision  of  what  enterprise  integration  might  look 
like  in  the  year  2001.  This  chapter  has  five  major  sections: 

•  Section  B.  1 ,  Electronics  Industry  1991.  Describes  the  current  state  of  enterprise 
integration  and  the  integration  infrastructures  used  in  achieving  the  current  state 
of  enterprise  integration. 

•  Section  B.2,  Electronics  Industry  2001.  Projects  what  an  integrated  enterprise 
and  its  supporting  integration  infrastructures  might  look  like  in  2001. 

•  Section  B.3,  Issues  and  Barriers.  Identifies  issues  that  must  be  addressed  to 
implement  enterprise  integration  today  and  barriers  that  must  be  overcome  to 
achieve  enterprise  integration  in  2001. 

•  Section  B.4,  Recommendations.  Provides  recommendations  for  achieving 
enterprise  integration. 

•  Section.  B.5,  List  of  Companies  Visited. 
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B.l  ELECTRONICS  INDUSTRY  1991 

The  information  discussed  in  this  chapter  is  based  on  visits  with  1 3  companies  in 
the  electronics  sector.  These  companies,  listed  in  Appendix  A,  cover  a  broad  spectrum  in 
the  electronics  industry  in  the  United  States,  from  semiconductor  manufacturers  to  diversi¬ 
fied  electronic  products  manufacturers,  including  workstation  vendors,  mainframe  comput¬ 
er  vendors,  and  defense  products  contractor.  Most  of  these  companies  are  multi-divisional 
and  have  revenues  well  in  excess  of  $1  billion  annually. 

To  set  the  background  for  our  discussion  of  enterprise  integration,  we  discuss  some 
characteristics  of  the  electronics  industry  that  affect  the  success  of  enterprise  integration 
projects.  There  are  four  commonly  observed  cultural  factors  among  companies  in  the  elec¬ 
tronics  sector:  technology,  competition,  innovation,  and  autonomy. 

Obviously  electronics  companies  use  technology  in  their  products,  but  it  is  equally 
important  that  they  are  also  among  the  early  adopters  of  technology  in  their  operations.  Per¬ 
haps  this  is  due  to  the  preponderance  of  individuals  with  engineering  backgrounds  at  the 
executive  management  level.  Whatever  the  cause,  it  is  significant  that  these  companies  are 
comfortable  with  technology  and  readily  turn  to  it  to  enhance  their  business. 

Competition  is  a  fierce  driver  among  companies  in  the  electronics  industry.  Time- 
to-market  is  a  critical  factor  in  business  success  for  this  sector.  It  is  well  known  that  a  few 
months’  delay  in  product  introduction  has  much  more  impact  on  a  product’s  overall  profit¬ 
ability  than  cost  overruns  of  50%  during  product  development.  Therefore  these  companies 
willingly  invest  in  initiatives  that  will  maintain  competitiveness,  increase  efficiency,  and 
reduce  time-to-market 

Innovation  is  key  to  remaining  competitive.  With  product  lifetimes  ranging  from 
less  than  two  years  to  as  many  as  five  years,  it  is  vital  to  reduce  development  cycles  and 
maintain  a  flow  of  new  product  innovation.  Some  innovation  occurs  in  response  to  compe¬ 
tition  and  some  occurs  in  anticipation  of  future  competitive  pressures.  Examples  of  respon¬ 
sive  innovation  are  reducing  the  cost  of  manufacturing  a  cellular  phone  in  response  to  price- 
pressure,  or  designing  a  faster  CPU  in  response  to  the  introduction  of  a  new  “hot  box’’ 
workstation.  An  example  of  anticipatory  innovation  is  developing  a  new  semiconductor 
process  to  keep  up  with  the  increasing  transistor  densities  forecast  by  Moore’s  Law.^  Thus 
the  ability  to  innovate  is  a  strategic  competitive  resource,  and  product  engineering  is  the 
most  influential  portion  of  an  electronics  company’s  staff. 

*  G.  Moore.  “VLSI:  Some  Fundamental  Challenges,”  IEEE  Spectrum,  April  1979,  pp.  30-37. 
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Most  electronics  companies  are  composed  of  many  very  autonomous  groups.  In 
part  this  is  due  to  divisionalization  and  the  diversity  of  products,  and  in  part  it  is  due  to  the 
innovative  character  of  electronic  product  development.  Many  product  lines  have  their  own 
profit  and  loss  responsibility,  and  ultimately  most  operational  decisions,  such  as  participat¬ 
ing  in  integration  projects,  are  left  to  each  profit  and  loss  center.  In  addition,  since  engineers 
must  be  innovative,  they  also  must  be  allowed  to  try  different  approaches  to  product  devel¬ 
opment.  This  fosters  a  corporate  culture  in  which  swimming  against  the  tide  is  accepted  and 
individual  preferences  are  given  ample  consideration. 

B.1.1  INTRODUCTION 

In  this  section  we  discuss  what  motivates  electronics  companies  to  initiate  enter¬ 
prise  integration  projects.  We  examine  common  elements  in  the  enterprise  integration  deci¬ 
sion  process,  what  are  some  of  the  drivers,  and  what  are  some  of  the  expected  benefits.  In 
addition,  we  discuss  the  enterprise  integration  enviromnent  and  observe  the  anomalous,  but 
not  unexpected,  homogeneous  computing  environment  that  occurs  at  a  computer  manufac¬ 
turer. 

Far  and  away  the  most  frequent  reason  given  for  having  started  an  enterprise  inte¬ 
gration  project  is  “we  had  to.”  Primarily,  this  is  based  on  an  intuitive  perception  that  an  inte¬ 
grated  operation  was  necessary  in  order  to  remain  a  competitive  and  viable  business  entity. 
Department  of  Defense  (DoD)  contractors  and  vendors  also  noted  required  compliance 
with  federal  regulations  and  initiatives,  such  as  the  CALS  (Computer-Aided  Acquisition 
and  Logistics  Support)  initiative. 

Most  companies  participate  in  some  form  of  competitive  benchmarking  in  which 
they  exchange  best  practices  information  about  their  business  with  a  few  firms  that  are  com¬ 
parable,  including  some  competitors.  Hie  information  exchanged  serves  to  characterize 
their  industry  without  disclosing  any  key  strategic  or  competitive  information.  If  there  is  a 
clear  trend  that  one’s  competitive  segment  is  pursuing  integration  along  some  particular 
axis,  then  it  would  be  very  uncomfortable  to  choose  to  be  the  laggard  and  risk  becoming 
non-competitive. 

As  a  consequence,  most  of  the  companies  visited  do  not  perform  a  cost-benefit  anal¬ 
ysis  to  justify  a  pending  enterprise  integration  project  Usually,  for  those  enterprise  integra¬ 
tion  projects  that  are  widely  implemented,  it  is  intuitive  that  the  benefits  far  exceed  the 
costs.  Where  the  benefits  of  an  enteiprise  integration  project  have  been  measured,  the 


results  have  ranged  from  about  break-even  to  significantly  leveraged  benefits.  (Some 
results  are  reported  in  Section  2.1.3  on  page  16.) 

Two  drivers  for  enterprise  integration  are  that  it  facilitates  collaboration  among 
groups  and  individuals,  and  that  an  integrated  enterprise  can  be  more  responsive  to  change. 
Ultimately,  enterprise  integration  requires  that  information  within  the  enterprise  be  effec¬ 
tively  available  across  functional  groups.  This  enables  individuals  in  different  groups  who 
need  to  share  information  to  access  the  same  information,  which  enables  them  to  work 
more  closely  together. 

An  integrated  system  is  more  responsive  to  change  than  is  a  non-integrated  system. 
Once  an  interface  to  a  component  of  an  integrated  system  has  been  developed,  then  it  is 
much  easier  to  add  another  unit  of  that  type  of  component  into  the  system.  So  one  value  of 
integration  is  to  minimize  the  cost  of  future  incremental  extensions. 

Most  integration  projects  not  only  automate  the  system,  but  they  also  re-engineer 
the  system.  That  is,  while  asking  how  does  the  current  system  work,  one  also  asks  how 
should  it  work.  This  originates  some  changes  in  business  operations  to  a  mote  effective 
operational  structure.  In  addition,  a  cleanly  architectured  integrated  system  will  be  respon¬ 
sive  to  business  change  in  the  future. 

The  integration  of  an  enterprise  tends  to  correlate  highly  with  its  quality  measures. 
Improved  quality  has  been  mentioned  consistently  as  a  benefit  of  successful  integration 
projects  reported  in  this  study.  It  is  interesting  to  note  that  while  all  companies  have  pro¬ 
grams  in  place  to  address  the  quality  of  their  products  and  processes,  only  one  reported  the 
quality  program  as  a  primary  driver  behind  specific  integration  projects. 

The  integration  infrastructures  that  underlie  enterprise  integration  fall  into  three 
domains:  high-speed  networks,  product  data  representation,  and  operational  information. 
In  most  companies,  the  choice  of  computing  platforms  (workstations  and  mainframe  com¬ 
puters)  dictate  the  kinds  of  networking,  operating  systems,  electronic  mail  (e-mail),  and 
other  interfaces  that  are  involved  in  implementing  enterprise  integration.  Note  that  confut¬ 
ing  platform  choices  are  sometimes  dictated  by  the  software  tools  that  are  used  within  the 
enterprise,  such  as  tools  for  computer-aided  design  (CAD),  computer-aided  integrated 
manufacturing  (CTM),  and  so  forth. 

The  typical  company  uses  multiple  networks,  with  various  network  protocols,  file 
systems,  and  client-server  mechanisms.  Integration  efforts  must  begin  by  bridging  or  har¬ 
monizing  the  disparate  network  components  into  a  uniform  environment.  It  would  be  a  sig- 


nificant  benefit  to  an  integration  project  to  be  able  to  bypass  this  initial  effort.  The  one  group 
of  companies  that  can  avoid  this  overhead  is  the  computer  vendors. 

For  those  companies  that  manufacture  computers,  there  is  a  strong  tendency  to  use 
their  own  products.  Thus  companies  like  DEC,  IBM,  Motorola,  and  NeXT  adopt  their  own 
platfoims,  networks,  and  file  systems.  This  has  the  benefit  that  the  system  tends  to  be  very 
homogeneous,  and  where  it  is  heterogeneous,  the  software  to  integrate  them  in  a  uniform 
way  is  already  in  place.  Thus  DEC  uses  DECNet,  IBM  uses  SNA  (Systems  Network  Archi¬ 
tecture),  and  the  others  use  network  file  system  (NFS)  and  TCP/IP  (Transmission  Control 
Protocol/Intemet  Protocol). 

A  company  that  begins  with  a  homogeneous  environment  has  an  inherent  advantage 
over  a  company  that  must  pay  the  overhead  of  network  integration.  This  advantage  occurs 
in  companies  in  the  electronics  sector  that  are  computer  vendors,  or  to  companies  who  have 
adopted  a  single  vendor’s  platforms. 

B.1,2  BUSINESS  STRATEGIES 

The  electronics  industry  competes  in  a  global  marke^lace  and  purchases  from  a 
global  supplier  base.  Most  electronics  companies  have  some  offshore  manufacturing  or 
assembly  facilities,  as  well  as  world-wide  distribution  channels. 

Because  of  the  diversity  in  the  electronics  sector,  each  company  has  strategies  that 
are  particular  to  its  business  areas.  We  note  that  following  strategies  are  common  across  the 
industry:  (1)  reduce  time-to-market,  (2)  be  iimovative,  (3)  reduce  cycle  times,  (4)  improve 
quality,  and  (5)  build  strategic  supplier  partnerships. 

Competition  for  the  U.S.  electronics  industry  comes  from  Europe,  Japan,  and  the 
rest  of  North  America,  but  certainly  U.S.  companies  are  highly  sensitive  to  competitive 
pressure  coming  from  Japanese  companies.  Four  of  the  strategies  cited  above  target  com¬ 
petitive  strengths  that  have  historically  been  associated  with  Japanese  competitiveness. 

Time-to-market  is  perhaps  the  single  most  important  factor  in  product  success.  Each 
of  the  four  strategies  cited  above  are  significant  contributors  to  reducing  time-to-market. 
Every  company  seeks  to  improve  and  lead  in  time-to-market.  Reduced  time-to-market 
enables  a  company  to  be  responsive  with  its  product  offerings  and  innovative  in  pursuing 
emerging  markets.  In  short,  reduced  time-to-market  enhances  competitiveness.  To  give  one 
example.  Motorola  has  reduced  its  tinK-to-maiket  for  cellular  phones  by  50%  over  the  last 
10  years. 
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A  key  asset  of  each  electronics  sector  company  is  its  engineering  resource.  The 
engineering  staff  embodies  the  intellectual  property  of  a  company  through  its  knowledge 
of  existing  product  designs  and  of  proprietary  engineering  processes.  And  engineering  is 
the  source  of  innovation.  Some  of  the  phrases  used  regarding  innovative  engineering  were 
“quality  people,”  “zealots  who  do  not  know  what  can’t  be  done,”  “rise  to  the  occasion,”  and 
“expect  a  miracle.” 

Automation  can  reduce  cycle  times  by  speeding  up  one  or  more  steps  in  the  process. 
Automation  can  also  reduce  cycle  times  by  eliminating  enors  and,  consequently  eliminat¬ 
ing  needless  repetition  of  process  steps.  Integration  can  reduce  cycle  time  by  facilitating 
faster  information  flow  to  the  individuals  who  need  that  information.  When  that  informa¬ 
tion  is  also  of  higher  quality  (such  as  an  error-free  design),  tlien  the  benefit  is  compounded. 

An  even  greater  effect  of  an  integration  project  on  cycle  time  can  be  obtained  when 
in  the  course  of  automating  several  processes  into  one  integrated  process,  the  processes  are 
re-engineered  into  a  more  efficient  process.  National  Semiconductor  replaced  a  multiple 
(six  steps  or  more)  step  manual  process  (in  selected  cases)  with  a  two-step  automated  pro¬ 
cess  while  integrating  its  order  entry  system  via  EDI  (electronic  data  interchange)  and  auto¬ 
mated  ordering  and  scheduling. 

Most  companies  visited  have  an  explicit  corporate  quality  strategy.  Their  programs 
are  called  by  various  names,  such  as  Total  (Quality  Management  (TQM),  NonStop  Quality, 
Six  Sigma,  and  Continuous  Improvement  Since  errors  introduce  distortion  into  cycle 
times,  an  effective  quality  program  will  contribute  to  reducing  cycle  times  and  time-to-mar¬ 
ket  For  a  semiconductor  product  quality  directly  affects  yield  which  determines  profitabil¬ 
ity. 

Establishing  strategic  supplier  relationships  involves  reducing  the  number  of  sup¬ 
pliers  and  building  partnerships  with  the  remaining  suppliers.  Westinghouse  Electronic 
Systems  Group  reported  reducing  firom  400  to  40  suppliers  of  machined  parts.  For  a  com¬ 
pany  to  maintain  a  relationship  with  a  supplier,  an  overhead  cost  in  excess  of  $ 1 ,000  is  esti¬ 
mated  to  occur.  Reducing  the  nur*ber  of  suppliers  results  in  a  direct  cost  savings. 

Having  a  strategic  relationship  between  a  company  and  a  supplier  benefits  both  par¬ 
ties.  The  supplier  can  anticipate  business  continuity  with  the  conrpany  and  can  make  longer 
term  investments  to  accommodate  the  company’s  way  of  doing  business.  Example  accom¬ 
modations  are  just-in-time  (JIT)  deliveries  on  a  per  day  or  per  shift  basis,  or  subscribing  to 
an  EDI  service.  The  company  can  work  with  the  supplier  to  adopt  some  of  the  company’s 


practices,  such  as  employing  the  same  quality  program  or  using  electronic  transfer  of  sche¬ 
matics  or  drawings  of  parts.  (The  company  will  control  access  to  its  proprietaiy  data  on  a 
need-to-know  basis  since  in  many  cases  a  supplier  has  a  sister  division  that  is  the  com¬ 
pany’s  competitor.) 

The  above  strategies  are  common  to  most  companies  in  the  electronics  sector.  In  the 
following  paragraphs  we  discuss  certain  strategies  that  are  particular  to  one  specific  elec¬ 
tronics  industry  segment. 

In  the  semiconductor  industry,  a  fundamental  strategy  is  to  improve  silicon  fabrica¬ 
tion  process  yield.  Moore’s  Law  sets  a  strategy  to  increase  transistor-per-chip  density 
through  a  combination  of  factors  including  larger  die  sizes  and  finer  (sub-half-micron)  pro¬ 
cess  technology.  The  industry  has  a  specific  cycle  time  reduction  strategy  in  its  fabrication- 
assembly-test  cycle.  National  Semiconductor  also  has  a  service  strategy,  where  they  add 
value  “by  offering  a  variety  of  important  services.” 

Strategies  peculiar  to  the  workstation  manufacturing  industry  include  the  “Hot 
Box”  strategy,  which  is  to  develop  workstations  based  on  reduced  instmction  set  computer 
(RISC)  architectures,  and  to  attempt  to  leap-frog  the  current  performance  parameters  of 
one’s  competitors.  Offering  an  open  architecture  is  another  common  workstation  strategy, 
although  no  single  open  architecture  standard  has  yet  emerged.  A  client-server  architecture, 
which  is  seen  as  a  key  enabler  of  integrated  systems,  is  a  significant  sub-strategy  of  the  open 
architecture  strategy. 

Another  sub-sdategy  is  adopting  object-oriented  technology  in  implementing  some 
facet  of  the  client-server  and  open  architecture  strategies,  for  example,  the  NeXT  Comput¬ 
er’s  NeXTStep  development  environment 

A  client-server  architecture  strategy  is  also  being  followed  by  mainframe  computer 
vendors.  They  are  positioned  to  provide  the  server  component  in  such  an  architecture,  and 
are  providing  server  facilities  such  as  Information  Resource  Dictionary  System  (IRDS)  of 
the  American  National  Standards  Institute  (ANSI)  standard  repositories.  Each  company’s 
strategy  is  to  do  this  in  the  context  of  its  proprietary,  homogeneous  network  architecture 
that  spans  from  mainframe  computers  to  workstation  and  personal  computer  products. 

Both  Hughes  and  Westinghouse  have  a  strategy  to  increase  their  commercial  prod¬ 
ucts  business  with  new  products  that  are  based  on  technology  developed  while  performing 
various  DoD  contracts.  In  part  this  is  driven  by  the  expected  downturn  in  defense  funding 
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during  this  decade.  They  need  to  move  from  a  business  dominated  by  one  customer  to  a 
more  even  mix  between  government  and  commercial  revenue. 

B.1.3  STATE  OF  INTEGRATION 

In  the  community  of  electronic  computer-aided  design  (ECAD),  it  has  been  said 
that  the  1 980s  were  the  decade  of  automation  of  point  tools  and  the  1 990s  will  be  the  decade 
of  integration.  What  has  been  said  about  the  integration  of  tools  in  E-CAD  can  also  truly 
be  said  about  the  integration  of  organizations  in  the  electronics  industry.  The  1980s  were 
the  decade  of  “islands  of  automation”  and  the  1990s  will  be  the  decade  of  enterprise  inte¬ 
gration. 

John  Tegethoff  of  Motorola’s  Corporate  Enterprise  Integration  staff  believes  that 
“there  is  more  payback  now  in  enterprise  integration  than  ten  years  ago.”  This  is,  in  part, 
attributed  to  economies  of  scale.  Although  a  common  definition  of  enterprise  integration 
has  not  emerged,  there  are  two  things  that  can  be  said  about  it  with  certainty:  enterprise 
integration  is  occurring,  but  the  approaches  being  taken  by  industry  are  different  Enter¬ 
prise  integration  is  not  happening  the  same  in  any  two  companies  (in  the  electronics  indus¬ 
try). 

In  this  section  we  discuss  the  state  of  enterprise  integration  in  1991  in  the  electron¬ 
ics  industry  sector.  First,  we  will  offer  some  general  observations  that  are  representative  of 
the  state  of  enterprise  integration  in  the  electronics  industry.  Second,  since  much  more 
enterprise  integration  is  happening  in  a  piecemeal  fashion  within  the  industry  than  is  hap¬ 
pening  at  any  one  company,  we  will  try  to  roll  this  activity  up  into  one  hypothetical  inte¬ 
grated  enterprise  and  describe  the  enterprise  integration  practices  that  could  be  attained 
today.  Third,  we  will  discuss  four  case  studies  of  successful  integration  projects  which 
reflect  the  state  of  different  aspects  of  enterprise  integration  today. 

An  enterprise  integration  view  of  the  enterprise  includes  all  agents  that  influence  the 
value-chain  of  the  enterprise’s  products.  TTiis  view  includes  the  enterprise’s  interactions 
with  its  suppliers  and  its  customers.  Thus  enterprise  integration  includes  both  intra-compa¬ 
ny  integration  and  inter-company  integration,  that  is,  both  integration  within  one  company 
and  between  different  companies. 

Most  integration  activities  today  are  intra-company.  Integration  projects  generally 
spring  from  a  need  to  exchange  information  among  groups.  The  groups  may  be  different 
organizations,  different  functional  entities  within  one  organization,  or  geographically  dis¬ 
persed  groups  within  one  functional  entity.  A  prerequisite  to  an  integration  activity  is  the 
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awareness  that  information,  which  would  be  beneficial  to  performing  one’s  task,  exists  in 
another  group.  If  this  awareness  is  coupled  with  an  agreement  between  the  groups  that  effi¬ 
cient  access  to  the  information  would  be  mutually  advantageous,  then  the  seeds  for  an  inte¬ 
gration  activity  are  present.  The  culture  and  infrastructure  that  enable  integration  are  much 
more  likely  to  occur  within  a  company  than  across  company  boundaries.  As  a  result,  almost 
all  integration  projects  are  internal  to  one  company. 

A  fundamental  integration  activity  that  underlies  and  enables  many  other  enterprise 
integration  activities  is  widespread  peer-to-peer  communication.  Most  electronics  compa¬ 
nies  have  corporate-wide  (and  world-wide)  computer  networks  with  electronic  mail  facili¬ 
ties  available  to  exchange  e-mail  among  any  two  computer  users.  DEC,  Hughes,  Intel, 
IBM,  Motorola,  NeXT  and  Texas  Instruments  each  explicitly  talked  about  their  e-mail  sys¬ 
tems.  The  efforts  to  bridge  multiple  e-mail  systems  (e.g.,  between  personal  computer  users 
and  workstation  users)  and  to  administer  corporate-wide  user  identities  are  significant 
issues.  But  the  overwhelmingly  important  factor  is  to  implicitly  encourage  peer-to-peer 
communication  within  the  corporate  culture. 

The  most  frequently  encountered  integration  project  was  creating  a  product  data 
management  (PDM)  system  to  provide  the  “concurrent  engineering”  coupling  between 
design  engineering  and  manufacturing  engineering.  The  goal  of  this  integration  is  to  reduce 
the  cycle  time  to  provide  correct,  manufacturable  product  designs  to  manufacturing.  The 
payback  from  a  PDM  system  is  direct,  both  in  tite  intangible  sense  of  reducing  time-to-mar¬ 
ket  and  in  the  tangible  sense  of  cost  savings  by  avoiding  false  manufacturing  starts. 
Depending  on  how  far  an  incorrect  design  gets  into  the  manufacturing  cycle  before  the 
error  is  caught,  the  cost  is  measured  in  hundreds  of  thousands  or  millions  of  dollars. 

A  PDM  project  involves  formalizing  and  automating  the  design-release-ECO 
(engineering  change  order)  process.  It  uses  a  database  (electronic  vault,  repository  manag¬ 
er,  etc.)  to  keep  track  of  the  versions  of  each  design,  which  designs  are  used  as  components 
in  a  configured  design,  and  the  exact  configuration  of  versions  of  the  components  that  are 
used  in  each  version  of  the  configured  design.  Design  data  may  be  physically  transferred  to 
PDM  storage  or  it  may  remain  in  a  workstation’s  file  system  with  logical  ownership  trans¬ 
ferred  to  the  PDM  process.  Either  way,  the  PDM  system  controls  access  to  the  design  data 
and  provides  a  check-in/check-out  mechanism  that  synchronizes  access  and  changes  to 
designs.  The  PDM  system  will  enforce  that  the  released  version  of  a  design  is  accessible  as 
read  only,  that  changes  only  occur  to  a  new  version,  and  that,  at  most,  one  engineer  at  a  time 
is  making  changes  to  a  design. 


There  arc  many  views  of  a  design,  for  example,  a  logical  or  schematic  view  of  a  cir¬ 
cuit,  a  circuit  board  layout  view  to  materialize  the  circuit,  a  numerical  control  view  to  man¬ 
ufacture  the  circuit  board,  and  a  component  placement  view  to  manufacture  the  fully 
populated  board.  In  addition,  there  is  a  documentation  view  which  includes  both  engineer¬ 
ing  documentation  for  internal  use  and  product  documents  that  are  deliverables  for  the  cus¬ 
tomer.  All  of  these  views  may  be  reflected  in  data  elements  that  are  under  version  control 
unda  PDM  control  in  correspondence  with  released  design  data. 

The  most  frequent  automation  task  was  to  replace  microfiche  and  paper  design 
drawings  with  electronic  viewing  of  designs.  Hiis  is  synergistic  with  the  PDM  system  since 
electronic  distribution  of  the  current  released  version  of  a  design  interactively  is  both  ben¬ 
eficial  to  and  benefits  from  electronic  viewing  capability.  Paperless  design  distribution 
result  in  both  materials  cost  savings  and  time  savings.  An  integrated  enterprise  could  be 
paperless  except  that  for  legal  reasons  one  paper  copy  of  a  design  or  equivalent  document 
must  be  signed  and  archived  to  document  the  design  approval  process. 

In  addition  to  storing  both  source  design  data  and  derived  manufacturing  data,  sev¬ 
eral  companies  have  automated  the  translation  of  design  data  to  manufacturing  data  and 
programming  the  factory.  NeXT  Compute'  has  a  relatively  homogeneous  environnnent, 
with  PCB  (printed  circuit  board)  tools^  from  one  CAD  vendor  and  a  CIM  environment  con- 
troUed  on  NeXT  workstations.  They  have  inq)lemented  an  application  that  accesses  the 
CAD  file  across  the  network,  converts  it  to  machine  programs,  and  optimizes  those  pro¬ 
grams  for  placement  cycle  time  and  machine  wear.  Tektronix  uses  a  proprietary  neutral  for¬ 
mat  (Mitron’s  integrated  data  fornut  (IDF))  for  connectivity  and  XY  location  data,  and  they 
use  ICES  (Initial  Graphics  Exchange  Specification)  for  geometry.  They  have  built  one 
translator  from  each  PCB  tool  to  the  neutral  formats  and  one  translator  from  the  neutral  for¬ 
mats  to  each  machine  tool. 

Another  integration  linkage  between  design  and  manufacturing  is  the  approved- 
parts  database.  Design  engineers  identify  parts  to  be  placed  in  the  database  for  required 
functionality;  manufacturing  considers  the  options  among  parts  that  provide  equivalent 
functionality,  considering  such  characteristics  as  availability,  reliability,  usability,  and  man¬ 
ufacturability.  At  Motorola  Cellular  and  NeXT  Computer,  the  component  engineering 
organization  that  controls  the  approved-parts  database  is  in  the  manufacturing  organization. 
In  both  these  companies,  the  design  engineers  are  familiar  with  the  manufacturing  floor  and 

^  The  PCB  tools  used  by  NeXT  are  not  available  on  NeXT  workstations. 
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they  know  which  components  are  on-line.  In  addition,  the  design  engineers  participate  in 
starting  up  the  manufacturing  line  on  a  new  design. 

Although  most  integration  is  intra-company,  there  is  significant  inter-company  inte¬ 
gration.  Some  inter-company  integration  reflects  the  automation  of  sales  and  purchasing 
activities,  while  some  represents  extending  engineering  integration  to  suppliers. 

Following  the  lead  of  the  automotive  sector,  most  electronics  companies  are  adopt¬ 
ing  EDI  standards  for  issuing  purchase  orders  and  booking  orders,  and  are  making  pay¬ 
ments  by  electronic  funds  transfer.  However,  of  13  companies  surveyed,  only  3  reported 
using  EDI  for  both  their  customers  and  their  suppliers.  Intel  has  installed  equipment  capa¬ 
ble  of  communicating  via  EDI  at  its  smaUer  suppliers.  NeXT  Computer,  National  Semicon¬ 
ductor,  and  Motorola  have  integrated  their  EDI  order  entry  systems  with  factory  scheduling 
systems. 

It  is  not  uncommon  to  transmit  a  purchase  order  to  a  supplier  via  EDI  and  send  a 
hardcopy  attachment  that  contains  drawings  and  other  technical  data.  DEC,  Motorola,  Tex¬ 
as  Instruments,  and  Westinghouse  have  extended  their  systems  to  electronically  transfer 
drawings  to  suppliers.  Texas  Instruments  and  Westinghouse  have  each  placed  equipment 
for  downloading  and  viewing  drawings  at  their  smaller  suppliers.  In  each  case  the  company 
controls  access  to  the  design  data,  usually  placing  a  copy  of  the  drawing  file  on  an  isolated 
workstation  or  personal  computer  that  is  then  accessed  by  the  supplier.  Generally  the  out¬ 
side  supplier  does  not  connect  to  the  engineering  network  of  the  company. 

It  is  appropriate  at  this  point  to  acknowledge  the  issue  of  the  so-called  “legacy  sys¬ 
tems.”  A  legacy  system  is  a  software  system  fitat  writes  data  (to  disk)  in  a  proprietary  for¬ 
mat  A  legacy  system  may  also  have  specialized  platform  requirements,  such  as  a  specific 
release  of  operating  system  software.  This  becomes  an  issue  when  the  data  has  a  long  life¬ 
time  and  the  volume  of  the  data  is  very  large  so  that  it  is  infeasible  or  prohibitively  costly 
to  convert  the  data  into  a  new  system.  A  legacy  system  might  be  a  database  management 
system  that  uses  a  hierarchical  or  network  data  model  (e.g.,  information  management  sys¬ 
tem  (IMS)  or  integrated  data  management  system  (IDMS)),  or  it  might  be  a  CAD  system 
that  writes  a  proprietary  binary  design  file  format 

Integration  of  a  legacy  system  is  generally  difficult  Typically  it  does  not  support 
interactive  access  to  its  data,  neither  by  query  nor  by  procedural  interface.  Usually  a  special 
ad  hoc  application  or  report  generation  program  must  be  written  to  navigate  through  the 


data  and  extract  the  desired  information.  To  integrate  a  legacy  system,  there  are  three 
options  to  choose  from; 

a.  Use  manual  integration,  where  the  legacy  system  is  used  in  the  usual  manner  and 
a  human  manually  links  the  legacy  system’s  information  into  the  rest  of  the  sys¬ 
tem. 

b.  Encapsulate  the  legacy  system,  whae  a  very  general  application  program  (called 
a  wrapper)  is  written  for  that  specific  legacy  system.  The  wrapper  will  accept 
data  requests  for  the  legacy  system  and  its  application  is  to  emulate  a  query  of 
interactive  interface  against  the  legacy  system. 

c.  Displace  the  legacy  system,  maintaining  it  for  archival  purposes  only.  This  can 
be  done  in  an  evolutionary  manner  by  extracting  and  converting  data  on  a  “as 
accessed”  basis.  There  is  the  possible  overhead  factor  that  botii  the  legacy  sys¬ 
tem  being  displaced  and  the  new  replacement  system  must  be  operated  in  paral¬ 
lel  for  some  period  until  references  to  unconverted  data  have  ceased,  at  which 
time  the  legacy  system  can  be  mothballed  and  only  the  replacement  system  car¬ 
ries  on. 


B.l  J.]  An  Int^ration  Scenario 

The  integration  technology  and  infirastructure  elements  available  today,  in  1993, 
would  enable  an  enterprise  to  develop  a  significant  integration  infirastructure.  However, 
integration  projects  are  constrained  by  culuiral  inertia,  financial  and  resource  limitations, 
and,  significantly,  risk  management  Thus  enterprise  integration  projects  and  their  support¬ 
ing  integration  infrastructures  tend  to  be  deployed  in  an  incremental  and  evolutionary  man¬ 
ner.  Since  each  enterprise  chooses  its  integration  path  based  on  particular  business  needs, 
the  corporations  visited  in  this  study  each  presented  a  different  road  map  of  integration 
efforts  to  date  and  a  unique  snapshot  of  current  integration  infrastructure. 

The  following  scenario  presents  the  profile  of  a  hypothetical  integrated  enterprise. 
This  profile  synthesizes  the  best  practices  of  10  corporations  visited  by  the  Electronics  Sec¬ 
tor  Team  for  this  study.  All  the  integration  infrastructure  elements  and  integration  practices 
described  in  the  scenario  are  based  on  current  technology  and  have  been  validated  by 
deployment  in  at  least  one  company  visited.  Figure  B-1  depicts  this  profile  of  an  integrated 
electronics  enterprise. 

The  seven  boxes  in  Figure  B-1  represent  seven  key  actors  (functional  groups)  in  the 
domain  of  an  enterprise.  The  main  horizontal  axis  corresponds  to  the  product  value  chain 
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Enterprise  Integration  Activities; 

1 .  Transmit  purchase  orders  to  suppliers  electronically  using  EDI. 

2.  Deliver  drawings  and  schematics  to  suppliers  electronically. 

3.  Receive  product  orders  from  customers  electronically  using  EDI . 

4.  Schedule  deliveries  electronically  using  factory  capacity,  inventory,  and  work-in¬ 
progress  databases. 

5.  Compute  manufacturing  schedules  based  on  inventory,  capacity,  orders  and  deliv¬ 
ery  commitment  databases. 

6.  A^ly  downstream  rules  in  design  process. 

7.  Approve  design  using  automated  design  approval  process. 

8.  Release  approved  design  to  manufacturing  via  an  electronic  vault. 

9.  Develop  parts  database,  parts  approved  by  design  and  manufacturing. 

10.  Compile  manufacturing  control  programs  for  PCBs  from  design  database. 

11.  Plan  and  optimize  manufacturing  control  programs  based  on  manufacturing 
schedules. 

12.  Print  manuals  and  documentation  on  demand,  custom  configured  to  product  op¬ 
tions. 

13.  Use  repair  history  database  feecl>ack  to  improve  precision  of  service  diagnostics. 

14.  Use  repair  history  database  to  drive  ECO/MCO  for  reliability. 

1 5.  Respond  to  customer  request  for  repair  or  warranty  services. 

16.  Manage  quality  programs  for  products,  using  design,  manufacturing  and  repair 
data. 

17.  Select  "corporate  standards,"  common  platforms,  tools,  and  other  technology  ele¬ 
ments  for  use  on  a  corporate-wide  basis. 

18.  Have  senior  management  sponsor  successful  integration  projects. 

EDI  ElMlronio  Data  MMthang* 

PCB  PrinladCireuitBaaid 

ECOMCO  Enginaaiing  Chang#  Oidai/Manulaoluhng  Chang#  Ordw 


Figure  B*l.  Functional  Groups  and  Processes  in  an  Integrated 
#  Electronics  Enterprise 
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of  suppliers-producer-consumers.  The  suppliers  provide  materials  and  component  assem¬ 
blies  to  the  producer,  and  the  consumers  purchase  the  products  manufactured  by  the  pro¬ 
ducer.  The  producer  is  partitioned  into  five  actors  in  the  research,  development,  and 
production  process:  managers,  design  engineers,  manufacturing  engineers,  technical  writ¬ 
ers  (documentation),  and  field  and  factory  service  engineers.  A  line  between  a  pair  of 
groups  indicates  an  information  flow  in  support  of  integration  of  their  activities. 

Eighteen  integrating  activities  or  integrated  processes  are  also  shown,  each  repre¬ 
sented  by  a  number  within  a  circle.  Where  the  number  is  placed  next  to  a  box  representing 
a  functional  group,  the  activity  is  undertaken  by  that  group.  Where  the  number  is  placed 
next  to  a  line  representing  an  information  flow,  the  activity  is  performed  to  the  mutual  ben¬ 
efit  of  both  functional  groups,  and  effects  some  of  the  information  flow  between  them.  In 
the  latter  case  the  activity  may  involve  using  data  from  both  groups  or  transferring  data 
from  one  group  to  the  other.  A  brief  description  of  each  activity  is  listed  in  the  figure  and 
each  is  described  more  fully  in  the  following  paragraphs. 

B.l  J.1.1  Suppliers,  Producers,  and  Customers 

EDI  is  used  to  exchange  business  information,  including  purchase  orders,  invoices, 
and  advice  of  payment  EDI  is  used  between  the  manufacturing  organization  and  its  suppli¬ 
ers,  and  between  customers  and  the  order  entry  organization  (activities  1  and  3).  EDI  may 
also  be  used  within  the  company,  between  divisions  that  have  a  supplier-consumer  relation¬ 
ship,  The  EDI  transmissions  to  suppliers  may  be  issued  by  manufacturing’s  MRP  (manu¬ 
facturing  resource  planning)  and  JIT  systems. 

For  electronic  components,  a  purchase  order  must  have  an  attached  schematic  or 
technical  drawing.  Since  EDI  supports  only  the  transfer  of  business  forms,  drawings  must 
be  transmitted  via  a  supplementary  mechanism  (activity  2),  such  as  an  interchange  format 
for  the  CAD  system  in  which  the  drawing  was  created,  an  industry  standard  graphics  inter¬ 
change  format  (e.g.,  IGES),  a  neutral  documentation  exchange  format  (e.g..  Standard  Gen¬ 
eralized  Marktip  Language  (SGML)),  or  a  proprietary  format  used  by  the  enterprise. 
Frequently,  a  supplier  will  not  have  the  necessary  equipment  or  software  required  to  receive 
drawings,  and  for  smaller  suppliers  the  purchaser  will  install  a  system  for  electronically 
viewing  drawings  in  the  supplier’s  facility.  For  security  reasons,  drawings  being  transferred 
to  a  supplier  are  either  downloaded  to  the  supplier’s  workstation  or  copied  to  an  isolated 
workstation  in  the  producer’s  plant  that  the  supplier  can  access  as  needed.  In  neither  case 
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is  the  outside  supplier  given  access  to  the  engineering  network  of  the  purchaser,  and  nor¬ 
mally  the  purchaser  is  not  given  access  to  the  network  of  the  supplier. 

During  the  process  of  ordering  an  electronic  component,  particularly  components 
available  from  multiple  sources,  the  customer  will  seek  a  committed  price  quote  and  deliv¬ 
ery  schedule.  Data  involved  in  responding  include  finished  inventory  data,  work-in-process 
data,  and  manufacturing  capacity  data.  The  order  entry  system  will  access  these  data  from 
their  various  sources  within  the  company  in  responding  to  the  customer  (activity  4). 

B.13.U  Design  and  Manufacturing 

A  flexible  CIM  facility  can,  in  principle,  manufacture  product  in  lot  sizes  of  one 
unit,  although  there  are  many  potential  factors  that  favor  larger  manufacturing  runs.  Sched¬ 
ules  for  each  manufacturing  line  are  computed  periodically,  the  frequency  depending  large¬ 
ly  on  lot  sizes  and  setup  overhead.  (A  line  with  a  setup  time  of  4  hours  might  be  scheduled 
weekly,  while  a  line  with  a  setup  time  of  1 S  minutes  might  be  scheduled  prior  to  each  shift) 
The  scheduling  activity  (activity  S)  uses  order  and  delivery  conunitment  data,  finished 
product  work-in-progress  and  materials  inventories,  and  manufacturing  capacity  informa¬ 
tion. 

Practicing  concurrent  engineering,  a  design  engineer  obtains  feedback  about  the 
suitability  of  the  emerging  design  for  downstream  processes  in  order  to  efficiently  produce 
a  high  quality  design.  The  feedback  may  be  provided  through  tools  run  by  the  design  engi¬ 
neer  (e.g.,  an  expert  system)  or  it  may  be  provided  by  a  formal  or  informal  review.  For 
example,  by  running  an  ASIC  design  through  a  design  rule  checker  using  appropriate 
design  rules  and  parameters  (activity  6),  the  design  engineer  verifies  that  the  design  con¬ 
forms  to  the  ASIC  foundry’s  process  rules. 

When  a  design  engineer  completes  a  design  or  an  engineering  change  and  the 
design  is  ready  for  release,  it  goes  through  an  approval  process.  An  approval  form  giving 
the  name  and  version  of  the  design  is  routed  by  electronic  mail  (activity  7)  for  the  required 
approvals,  which  may  include  the  designer,  a  quality  engineer,  the  project  lead,  and  one  or 
more  additional  managers.  A  password-verified  signature  is  entered  electronically  for  each 
signer.  After  the  electronic  design  approval  has  been  completed,  the  design  proceeds  in  the 
release  process  while  a  paper  approval  form  is  circulated  in  parallel  for  signature.  The  latter 
approval  form  is  required  because  electronic  signatures  have  not  been  established  as  legally 
binding  should  they  be  required  for  contractual  purposes. 


In  the  release  process  (activity  8),  the  approved  configuration  of  the  design  (the  cor¬ 
rect  version  of  the  design  and  the  correct  versions  of  the  components  used  in  the  design)  is 
checked  into  an  electronic  vault.  There  it  is  available  on  a  “read-only”  basis  to  both  design 
engineering  for  reuse  in  future  design  activities,  and  to  manufacturing  engineering  for 
developing  the  CIM  programs  used  in  the  manufacture  of  that  design. 

When  designing,  an  engineer  uses  some  purchased  components.  These  components 
are  selected  from  the  shared  corporate  approved-parts  database.  Frequently  there  is  a  choice 
among  several  options  for  parts  that  provide  the  required  functionality;  perhaps  a  choice 
among  options  >vith  identical  functionality,  but  from  different  suppliers.  In  this  case  the 
choice  may  be  based  on  manufacturability  issues.  (For  example,  by  choosing  a  chip  already 
in  use  on  the  manufacturing  line,  one  might  avoid  additional  setup  time  to  custom  load  an 
alternative  chip  into  a  “pick-and-place”  machine.)  Manufacturability  information,  such  as 
reliability,  maintainability,  and  usage,  is  collected  and  used  by  the  manufacturing  engi¬ 
neers,  so  the  approved  corporate  approved-parts  database  is  selected  (activity  9)  either  by 
manufacturing,  or  jointly  by  design  and  manufacturing,  with  manufacturing  having  veto 
power. 

To  manufacture  a  PdB,  a  numerical  control  (NC)  program  for  control  of  the  fabri¬ 
cation,  drilling,  stuffing,  and  soldering  processes  must  be  developed.  The  approved  design, 
as  placed  in  the  electronic  vault,  is  the  specification  for  the  NC  program.  Manufacturing 
acquires  the  PCB  design  firom  the  vault  and  compiles  the  NC  program  (activity  10). 

Some  optimization  of  an  NC  program  is  done  during  its  development  (i.e.,  in  activ¬ 
ity  10).  Much  of  the  optimality  of  the  CIM  operation  of  a  facility  depends  on  interactions 
among  the  various  NC  programs  for  the  parts  and  products  being  manufactured  in  that  facil¬ 
ity.  Therefore,  after  the  manufacturing  schedule  for  the  facility  is  established  for  the  day 
(week,  etc.),  further  CIM  optimization  is  performed  (activity  11).  This  optimization  is 
based  on  the  CIM  NC  programs,  the  schedule  (from  activity  5),  and  the  materials  inventory, 
and  outstanding  JIT  purchases  (activity  1). 

B.U.U  Documentation  and  Service 

Documentation  in  support  of  products  is  produced  by  many  groups.  It  is  all  collect¬ 
ed  into  a  documentation  database,  and  no  inventory  of  printed  manuals  is  maintained  (other 
than  a  supply  of  blank  paper  for  the  printing  process).  When  a  unit  of  product  is  prepared 
for  shipping  to  the  customer,  a  manual  customized  to  describe  exactly  and  only  the  features 
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in  that  product  unit  is  printed  on  demand  (activity  12)  just  in  time  for  inclusion  in  the  ship¬ 
ment. 

As  a  side  benefit,  service  documentation  reflecting  the  particular  requirements  and 
idiosyncracies  of  the  exact  product  configuration  of  a  unit  under  repair  can  be  read  electron¬ 
ically  by  a  service  engineer.  This  allows  the  engineer  to  focus  on  the  failure  modes  and 
repair  steps  that  are  relevant  to  the  repair  task  at  hand.  Thus,  the  same  diagnostic  results  for 
two  different  configurations  of  a  product  might  be  correlated  with  two  different  types  of 
failure.  By  capturing  a  reliability  and  repair  history  database  (activity  13),  manufacturing 
and  so^ice  can  detect  such  patterns  and  guide  the  service  engineer  to  a  precise  diagnosis 
and  an  efficient  repair  process. 

Using  the  reliability  and  repair  history  database,  service  engineers  can  detect  (activ¬ 
ity  14)  a  recurring  pattern  of  poor  reliability  or  failures.  Service  engineers  can  describe  to 
design  and  manufacturing  groups  this  pattern  and  together  they  can  arrive  at  an  ECO  or  an 
MCO  that  will  address  the  problem. 

After  an  order  is  delivered  and  installed,  most  interaction  with  the  customer  is  per¬ 
formed  by  the  field  service  engineers.  By  establishing  e-mail  or  EDI  communications 
between  the  customer  and  the  service  engineer,  customer  requests  for  service  (activity  15) 
are  received  with  greater  timeliness  and  accuracy  than  those  manually  received  and  pro¬ 
cessed,  and  electronic  communications  provide  the  opportunity  to  capture  this  feedback  for 
the  reliability  database. 

B.U.1.4  Management 

Quality  programs,  such  as  continuous  product  improvement  (CPI),  Six  Sigma,  or 
TQM,  require  accurate  and  timely  data  on  all  products.  All  functions  in  the  enterprise  (e.g., 
design,  manufacturing,  service,  management)  must  collect  accurate  data  appropriate  to 
quality  measurement  To  manage  the  quality  of  an  enterprise  (activity  16)  requires  electron¬ 
ic  access  to  the  appropriate  data  firom  these  disparate  sources,  coupled  vrith  the  ability  to 
integrate  the  data  into  a  model  that  enables  correlation  of  the  overall  quality  of  a  product 
with  the  data  elements  from  the  various  functions. 

Selection  of  conunon  tools  and  platforms  (activity  17)  has  two  positive  effects. 
First,  it  minimizes  the  cost  of  training  and  support.  Second,  it  enables  the  tool  users  to  focus 
on  fewer  tools  and  to  spend  more  time  on  using  them  well;  this  indirectly  increases  the  qual¬ 
ity  of  the  products  produced  using  these  tools. 
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Successful  integration  projects  are  characterized  by  bottom-up  opportunities  and 
top-down  sponsorship.  Opportunities  to  integrate  two  related  activities  or  a  common  activ¬ 
ity  in  two  separate  but  related  organizations  are  first  visible  to  the  two  groups  whose  activ¬ 
ities  would  benefit  from  their  integration.  Management,  particularly  a  manager  whose 
domain  of  control  spans  both  groups,  must  embrace  such  an  opportunity  and  provide 
enabling  sponsorship  (activity  18)  to  the  individuals  who  will  execute  the  integration 
project 


B.13.2  Success  Stories 

In  this  section  we  will  describe  briefly  five  integration  projects  that  have  been  suc¬ 
cessful.  They  are  National  Semiconductor’s  Automated  Semiconductor  Planning  and  Con¬ 
trol  System  (ASPC),  Digital  Equipment  Corporation’s  Engineering  to  Manufacturing 
BRIDGE  System,  NeXT  Computer’s  CIM  operation  and  automated  factory,  and  Texas 
Instruments’  Product  Drawing  Control  System  and  Order  Entry  Software  System. 

National  Semiconductor  •  ASPC 

For  National  Semiconductor,  the  manufacturing  process  has  four  steps:  fabrication, 
sort,  assembly,  and  test  Between  sort  and  assembly,  the  dies  are  placed  in  a  die  bank  which 
provides  the  die  inventory  for  the  assembly  operation.  The  second  half  of  this  process  is 
automated,  from  the  die  bank  to  completion.  Also  the  sales  and  marketing  is  automated, 
with  70%  of  orders  received  via  EDI.  ASPC  integrates  the  assembly  operation  with  the 
sales  operation. 

ASPC  automates  quoting  delivery  times  during  order  processing,  based  on  inven¬ 
tory  in  the  die  bank  inventory,  work-in-progress,  and  the  capacity  of  the  assembly  plants. 
Prior  to  ASPC,  a  quote  guide  was  used  that  gave  projected  delivery  times  for  each  National 
product,  based  on  average  order  quantities  and  frequency  of  orders. 

A  pilot  system  for  ASPC  is  operational,  covering  about  7%  of  National’s  part  num¬ 
bers.  On-time  delivery  for  these  parts  rose  from  less  than  88%  to  98%  when  delivery  time 
estimates  were  based  on  the  quote  guide  using  the  system’s  delivery  dates. 

ASPC  also  puts  out  a  report  to  the  factory,  on  a  daily  basis,  giving  its  proposed 
schedule  for  assembly  that  day.  ASPC  could  automatically  schedule  the  assembly  lots  for 
the  day,  but  the  factory  management  prefers  to  evaluate  the  report  and  manually  release  the 
requested  lots  into  their  shop  floor  system.  A  positive  side-effect  of  ASPC  is  a  leveling  of 
assembly  orders  and  the  correlated  inventory  control.  Prior  to  ASPC,  orders  tended  to  be 
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very  bi-modal,  with  all  deliveries  scheduled  for  the  1  st  or  16th  of  each  month,  and  each  fac¬ 
tory  tended  to  have  at  least  15  days  of  inventory  on  hand.  Now  just-in-time  (JIT)  inventory 
deliveries  can  be  leveled  out  and  reduce  the  actual  level  of  inventory  on  hand. 

Digital  Equipment  Corporation  •  BRIDGE 

Digital  Equipment  Corporation’s  Engineering  to  Manufacturing  BRIDGE  system 
was  developed  to  provide  product  data  management  on  the  VAX  9000  project.  BRIDGE 
provided  design-to-manufacturing  coupling  for  the  VAX  9000  product,  including  with  out¬ 
side  suppliers.  BRIDGE  coupled  engineering  and  manufacturing  groups  in  California,  Ire¬ 
land,  Massachusetts,  and  Vermont,  leveraging  off  the  infrastructure  provided  by  the  DEC 
corporate  network. 

Because  of  the  anticipated  complexity  of  the  product,  and  based  on  the  experience 
of  the  preceding  VAX  product,  DEC  felt  that  the  BRIDGE  system  may  make  the  difference 
between  a  viable  and  a  non-viable  product  development  effort.  While  developing  BRIDGE 
they  sought  to  re-engineer  the  product  data  management  and  release  process,  rather  than 
automate  the  existing  system. 

The  data  elements  managed  by  BRIDGE  are  documentation,  drawings,  CAD  files, 
and  product  descriptions.  Design  engineers  work  on  new  versions  in  their  own  workspaces. 
When  the  design  is  ready  for  release  and  has  received  management  sign-off,  it  is  checked 
into  the  BRIDGE  system.  Following  a  check-in  event,  BRIDGE  notifies  users  who  need  to 
know  about  it  Those  users,  either  designers  or  manufacturers,  then  access  the  new  version 
of  the  data  element  in  BRIDGE. 

Notification  that  a  new  change  has  taken  place  is  sent  to  users  dependent  on  that 
data  element  by  automatically  generating  e-mail  messages.  Those  users  subscribe  to 
BRIDGE  for  notification  of  various  changes  of  process  state  (e.g.,  creation  of  a  new  ver¬ 
sion)  on  a  specific  part  or  combination  of  parts.  BRIDGE  reduced  the  release  and  dissemi¬ 
nation  time  for  a  new  version  of  a  design  from  3  weeks  to  under  2  hours  (the  average),  with 
20  minutes  as  the  best  time. 

Suppliers  accessing  data  from  BRIDGE  connect  to  a  spur  network  that  is  isolated 
from  the  DEC  engineering  network.  They  issue  dieir  access  requests  to  a  BRIDGE  server 
on  the  isolated  network,  where  the  server  knows  how  to  validate  the  access  permission, 
locate  the  data  element  (by  forwarding  the  request  to  the  appropriate  BRIDGE  server  node 
on  the  corporate  network),  acquire  a  copy  of  the  data  on  the  spur  network,  and  disconnect 
the  q)ur  network  from  the  main  network.  The  supplier  then  accesses  this  copy  in  an  isolated 
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environment,  but  if  notification  comes  of  a  change  to  the  data  element,  a  request  for  the  new 
version  will  cause  the  copy  on  the  spur  to  be  updated. 

BRIDGE  is  now  well  accepted,  a  way  of  life,  although  the  acceptance  was  gradual 
and  involved  cultural  change.  One  quote  from  the  manufacturing  side  was  that  a  'design  is 
not  done  until  it’s  checked  into  the  BRIDGE  system.” 

Several  metrics  attest  to  the  success  of  BRIDGE: 

•  One  system  administrator  versus  ten  in  other  system. 

•  Two-and-a-half  data  coordinators  versus  twelve  to  fifteen  on  preceding  product. 

•  Two  hours  to  disseminate  new  version,  versus  three  weeks  previously. 

•  No  version  control  errors  during  development  of  the  VAX  9000. 

One  version  error  would  have  been  more  costly  than  the  development  cost  of  the 
BRIDGE  system.  The  configuration  and  version  control  meta-data  was  stored  in  a  DEC 
proprietary  object-oriented  database  management  system  (DBMS). 

NeXT  Computer 

The  next  success  story  presented  will  be  the  CIM  at  NeXT  Computer.  When  build¬ 
ing  its  manufacturing  facility,  NeXT  had  the  benefit  of  starting  with  a  clean  slate  and  having 
a  capable  workstation  product  upon  which  to  base  the  system. 

NeXT  adopted  three  CIM  strategies: 

•  Strive  for  a  single-layer  information  architecture. 

•  Create  object-oriented  software  tools,  eliminating  non-value-added  CIM  work. 

•  Develop  quality  control  systems  based  on  real-time  access  to  all  the  data. 

For  coupling  between  design  and  manufacturing,  NeXT  implemented  a  translator, 
called  MENTRANS,  that  takes  PCB  CAD  files  as  input  and  compiles  machine  programs  to 
control  the  assembly  operations.  The  first  translation  takes  a  few  seconds  for  a  1  megabyte 
CAD  file.  The  machine  programs  are  then  optimized  for  cycle  time  and  machine  wear  with¬ 
in  four  minutes. 

The  manufacturing  line  is  controlled  by  NeXT  workstations.  The  bulk  of  the  codes 
controlling  the  assembly  line  is  for  sequence  logic  and  data  gathering,  which  are  handled 
at  the  workstation.  A  minority  of  the  code  is  actually  at  the  robot  level,  to  pick  or  place  a 
component. 
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NeXT  uses  an  approved  parts  list  that  is  “owned”  by  manufacturing.  On  the  first 
NeXT  circuit  board,  manufacturing  vetoed  35  components  proposed  in  the  original  design, 
due  to  considerations  such  as  reliability  or  manufacturability.  To  further  strengthen  the  cou¬ 
pling  between  design  and  manufacturing,  all  prototypes  are  assembled  on  the  manufactur¬ 
ing  line;  this  could  not  be  done  without  the  ability  of  the  MENTRANS  system  to 
automatically  create  an  assembly  program  directly  from  the  CAD  design.  Once  a  design 
enters  full  manufacturing,  the  designer  participates  in  manufacturing  start-up. 

The  workstations  that  control  the  workcells  also  monitor  the  workcells  and  capture 
data  on  their  operation.  Analysis  of  quality  data  can  be  exhaustive  and  more  accurate  than 
if  based  on  statistical  sampling.  Manufacturing  engineers  can  access  historical  data  about 
processes,  components,  and  materials.  Management  (world-wide)  can  monitor  the  opera¬ 
tion  of  the  manufacturing  facility  in  real  time. 

Texas  Instruments 

We  will  conclude  this  section  by  presenting  two  integration  projects  at  Texas  Instru¬ 
ments.  The  first  is  Product  Drawing  Control  System  (PDCS),  an  electronic  drawing  control 
system  used  in  the  Defense  Systems  and  Electronics  Group  (DSEG).  The  second  is  Tooling 
and  Information  Engineering  System  (TIES),  a  system  to  manage  tooling  and  information 
(e.g.,  photomask  data)  used  in  the  Semiconductor  Group. 

The  goal  of  the  PDCS  is  to  provide  electronic  distribution  of  drawings  and  to  pro¬ 
vide  paperless  viewing  of  designs.  PDCS  provides  an  on-line  optical  disk  storage  server 
and  softcopy  software  used  to  view  a  drawing  on  a  workstation. 

Drawings  are  stored  in  two  forms  in  PDCS.  One  form  is  CAD-system  dependent, 
using  the  native  CAD  file  from  whatever  CAD  system  was  used  to  create  the  design  (e.g., 
AutoCAD  or  ComputerVision).  The  second  form  is  a  plotfile  in  either  Hewlett  Packard 
Graphics  Language  (HPGL)  or  Calcomp  plotter  format.  If  a  viewer  has  the  proper  CAD 
system,  the  file  can  be  viewed  using  the  native  CAD  file.  Softcopy  can  be  used  to  view  any 
drawing  in  the  system,  accessing  the  plotfile.  There  are  over  25,000  drawings  in  PDCS, 
occupying  over  1 1  gigabytes  of  optical  disk  storage. 

The  lifetime  of  a  drawing  in  PDCS  is  at  least  15  years.  It  is  very  important  that  the 
system  provide  very  high  integrity  of  design  identity.  When  two  people  have  accessed  a 
drawing,  they  must  be  able  to  guarantee  that  the  drawings  were  of  the  same  versions  of  the 
same  design.  This  is  provided  by  softcopy  using  a  PDCS -generated  trace  number,  which 
depends  on  the  design  identity  and  the  drawing  data,  like  a  checksum. 
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PDCS  still  uses  one  paper  copy  of  a  drawing  as  the  sign-off  signature  copy.  The 
trace  number  on  this  copy  can  be  matched  against  the  trace  number  rendered  by  softcopy 
each  time  the  drawing  is  viewed  to  confirm  that  the  released  version  of  the  drawing  is  being 
used. 

DSEG  does  the  majority  of  its  procurement  electronically.  The  purchase  order  is 
sent  using  EDI.  They  also  transfer  PCB  data  files  (e.g.,  tooling  data)  to  the  vendor  electron¬ 
ically.  DSEG  used  to  send  paper  copies  of  the  drawings  as  an  attachment  to  the  electronic 
transaction.  Now,  with  PDCS,  they  can  transfer  the  plotfile  to  a  vendor  who  can  view  the 
drawing  (or  plot  a  hardcopy  of  it)  on  site.  The  softcopy  software  requires  a  plotter  and  a 
workstation,  which  may  be  an  IBM-compatible  personal  computer,  at  the  vendor’s  site.  For 
access  control,  an  approved  Texas  Instruments  person  must  transfer  the  drawing  data  to  the 
vendor’s  workstation. 

Presently  about  1%  of  the  DSEG  vendors  use  softcopy.  Paper  is  used  for  legacy 
projects  that  were  begun  prior  to  deployment  of  PDCS. 

Softcopy  provides  a  red  line  editing  capability.  A  red  lined  drawing  may  not  be 
placed  in  PDCS,  but  it  can  be  transferred  to  a  designer  outside  of  PDCS.  The  designer  can 
make  those  edits  in  the  proper  CAD  tool  and  place  a  new  version  of  the  drawing  in  the 
PDCS  system,  following  the  normal  release  process. 

The  time  to  release  a  drawing  is  the  same  using  PDCS  as  it  was  previously,  since  it 
involves  carrying  a  paper  copy  of  the  drawing  around  for  signature.  The  time  to  obtain  a 
copy  of  a  drawing  has  been  reduced  from  nine  minutes  to  less  than  four  minutes. 

TIES  manages  filling  orders  for  photomasks.  The  orders  come  from  a  wafer  fabri¬ 
cation,  an  IC  design  engineer,  or  a  product  engineer.  TIES  will  access  the  design  files  and 
invoke  generation  of  the  appropriate  photomasks.  TIES  will  also  archive  the  data  necessary 
to  reproduce  the  masks. 

The  goals  of  TIES  are  the  following: 

a.  To  reduce  the  cycle  time  from  placement  of  a  photomask  order  to  receiving  the 
required  photomasks. 

a.  To  eliminate  photomask  generation  and  documentation  errors. 

b.  To  reproduce  masks  for  the  lifetime  of  that  product 

TIES  will  leverage  the  existing  Photomask  Order  Entry  System  database  and  the  T1 
world-wide  network  facility.  In  1990,  a  photomask  order  was  placed  in  the  Order  Entry 
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System,  and  then  manual  actions  caused  the  location  of  the  source  for  photomask  genera¬ 
tion  (e.g.,  a  layout  design  file),  submission  of  photomask  generation,  verification,  and 
release  of  the  photomask  generation  data.  Currently  this  process  is  time  consuming  and 
error  prone. 

TIES  automates  the  manual  actions  described  above.  It  reduces  the  cycle  time  by 
over  70  hours  per  order,  reducing  labor  costs  from  $420,000  to  $40,000,  a  savings  of 
$380,000.  TIES  also  makes  the  process  less  error  prone.  Prior  to  TIES  there  were  approx¬ 
imately  six  errors  per  year  that  were  not  caught  until  the  mask  reached  manufacturing.  In 
that  case,  the  average  error  costs  $100,000.  In  addition,  errors  cause  delays  and  redo  of 
mask  generation  effort.  Delays,  which  may  be  measured  in  months,  affect  time-to-market 
and  reduce  the  profitability  of  the  delayed  product. 

Because  a  photomask  may  be  reused  for  up  to  15  years,  TIES  must  have  the  ability 
^0  regenerate  a  mask  during  its  product  lifetime.  Another  component  of  the  TIES  architec¬ 
ture  is  DART,  the  Design  Archive  and  ReTrieval  database.  TIES  was  prototyped  basing 
DART  on  an  Oracle  database.  They  would  prefer  to  use  an  object-oriented  database  in  the 
future.  TIES  must  access  photomask  vendor  and  wafer  fabrication  data  from  legacy  infor¬ 
mation  management  system  (IMS)  databases. 

Currently  TI’s  world-wide  network  uses  an  SNA  (Systems  Network  Architecture) 
backbone  among  various  IBM  mainframe  computers.  TCP/IP  networks  of  workstations 
exist  in  each  facility  and  are  gatewayed  off  the  SNA  network.  They  are  working  on  provid¬ 
ing  a  second  connectivity  path  that  is  all  TCP/IP,  using  bridges  between  the  ethemet  net¬ 
works  of  various  facilities.  It  would  be  very  powerful  to  access  IMS  and  relational 
databases  across  the  network  in  real  time. 

Another  benefit  experienced  by  TIES  is  that  native  language  strings  in  electronic 
forms  are  orthogonal  to  the  forms  themselves.  So  the  same  mask  order  form  could  be  trans¬ 
mitted  to  Japan  and  to  the  United  States.  In  Japan,  the  form  would  use  Kanji  strings  when 
presented  on  a  workstation  screen  or  printed,  while  in  the  United  States  equivalent  English 
phrases  would  be  used. 

B.1.4  INTEGRATION  STRATEGIES 

In  this  section  we  will  highlight  15  integration  strategies  that  are  practiced  in  the 
electronics  sector  today.  TTie  first  10  strategies  are  widely  practiced  by  5  or  more  of  the  13 
companies  visited  by  the  electronics  sector  team  in  the  course  of  this  study.  Of  these  10 
strategies,  3  are  general  strategies  that  underlie  any  integration  activity.  The  other  seven  are 


specific  strategies  that  each  address  one  coupling  or  axis  of  integration.  The  final  five  strat¬ 
egies  are  not  widely  practiced,  but  are  considered  to  have  significant  merit  by  the  company 
or  companies  that  did  follow  these  strategies. 

B.1.4.1  Architect  the  Integrated  Enterprise 

A  successful  integration  must  bring  a  well-thought  out  structure  to  the  enterprise. 
Do  not  begin  by  automating  business  as  usual,  but  rather  figure  out  what  the  business  really 
does  and  streamline  it.  Align  the  structure  of  the  integrated  enterprise  with  its  goals  and 
objectives.  Lx)ok  for  redundant  or  unneeded  practices.  Ask  what  should  be  going  away. 
Explore  the  alternatives  for  replacing  an  existing  system  before  you  ask  if  it  should  be 
replaced. 

Process  modeling  is  one  way  to  determine  what  the  business  does.  It  takes  a  signif¬ 
icant  effort,  but  it  can  identify  needed  activities  (omissions),  redundant  activities,  and 
unnecessary  activities.  The  process  modeling  effort  should  avoid  coupling  its  model  with 
the  existing  way  of  doing  business;  for  example,  avoid  reflecting  organizational  structure 
in  the  process  model  and  avoid  acronyms  or  buzzwords  that  imply  ownership  of  a  process. 
Identify  processes  that  are  used  in  multiple  applications.  Use  the  correct  experts  in  devel¬ 
oping  and  validating  the  process  model. 

For  data,  avoid  assigning  ownership  of  data  to  organizations,  but  identify  a  process 
responsible  for  stewardship  of  each  data  element.  (Note  that  stewardship  can  be  reassigned 
at  any  time  it  becomes  appropriate.)  Consider  integrating  at  the  data  sources,  but  be  open 
to  integrate  at  any  site.  Collapse  two  or  more  processes  at  different  sites  to  one  process,  or 
co-locate  them  if  it  makes  sense. 

The  result  should  be  an  architecture  for  the  enterprise  and  a  complementary  inter¬ 
face  architecture  that  will  enable  the  processes  to  interact  to  implement  integration. 

B.  1.4.2  Recognize  the  Role  of  Autonomy 

As  discussed  in  section  B.I.l,  the  electronics  sector  companies  represented  in  this 
study  exhibit  individual  and  organizational  autonomy  within  their  corporate  cultures.  Out 
of  respect  for  such  autonomy,  integration  projects  are  not  imposed  top-down.  Rather,  inte¬ 
gration  proceeds  from  the  recognition  in  two  or  more  groups  that  they  are  working  to  per¬ 
form  the  same  processes  or  mutually  interacting  processes.  Generally  champions  will 
emerge  from  these  groups  who  will  propose  the  integration  project.  At  this  point,  most  suc¬ 
cessful  projects  find  a  sponsor  in  the  management  chain  to  whom  both  (all)  the  affected 


B-24 


groups  report.  The  combination  of  grass  roots  championship  and  common  management 
sponsorship  appears  in  most  successful  integration  projects. 

Thus  integration  projects  seek  to  combine  islands  of  automation.  During  the  inte¬ 
gration  project,  all  groups  should  continuously  display  their  buy-in  by  funding  or  staffing 
the  effort.  On  the  other  hand,  the  management  sponsor  should  be  alert  to  recognize  require¬ 
ments  of  the  project  that  should  be  provided  from  the  corporate  level.  For  example,  if  two 
groups  should  exchange  design  data  via  a  product  data  management  repository,  rather  than 
either  group  being  required  to  pay  for  the  repository  (which  appears  optional  to  their  oper¬ 
ation),  it  should  be  provided  as  a  centralized  corporate  resource. 

Once  an  integration  project  is  implemented  and  operational  among  the  first  two 
groups,  it  serves  as  a  showcase  system  for  other  groups  with  similar  needs.  Champions  in 
these  other  groups  will  quickly  line  up  to  extend  the  system  to  their  own  group.  Being  able 
to  add  new  clients  incrementally  is  a  significant  benefit  because  the  project  can  focus  its 
resources  on  the  new  client  and  improve  its  chance  of  success. 

B.1.4.3  Enable  Peer4o-Peer  Communication 

A  goal  of  integration  is  to  enable  cooperation  among  geographically  separated  sites. 
Motorola  describes  its  vision  as  the  wall-less  virtual  office.  It  is  important  that  an  individual 
with  a  need  to  know  certain  information  is  empowered  and  able  to  access  that  information 
wherever  it  may  be  within  the  enterprise.  A  requirement  for  this  capability  is  a  corporate- 
wide  network.  In  addition,  as  different  islands  of  integration  become  integrated,  high  qual¬ 
ity  peer-to-peer  communication  among  the  groups  is  essential.  One  facility  that  is  widely 
used  is  corporate  electronic  mail. 

The  next  six  subsections  discuss  some  specific  pair-wise  integration  opportunities. 

Increase  Order  Entry  and  Manufacturing  Coupling. 

There  is  a  mutual  co-dependence  between  order  processing  and  manufacturing; 
orders  are  limited  by  the  manufacturing  capacities,  work-in-process,  and  finished  goods 
inventories.  Manufacturing  must  schedule  its  capacity  to  produce  a  product  that  can  be  and 
is  being  sold,  and  the  schedule  must  not  cause  inventories  to  balloon  unnecessarily.  Most 
manufacturing  facilities  are  automated  to  the  extent  of  manuf[222zacturing  resource  plan¬ 
ning  (MRP)  and  JIT  systems.  A  first  step  in  automating  order  entry  is  to  accept  EDI  orders 
from  customers.  Then  this  on-line  order  information  can  be  used  to  order  materials  and 
schedule  manufacturing. 
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One  form  of  inventory  reduction  is  in  the  documentation  area.  For  many  products, 
the  configuration  of  options  used  in  one  unit  of  the  product  can  be  unique.  An  on-demand 
printing  system  can  print  the  documents  that  accompany  the  product  shipment  just  in  time 
as  the  product  is  manufactured,  and  can  be  custom  configured  to  the  product  as  built.  This 
capability  eliminates  document  inventories  and  enables  accurate  document  sets  to  accom¬ 
pany  the  product  ship.  Note  that  the  documents  will  be  accurate  both  in  the  sense  of  being 
properly  configured  to  match  the  product  unit,  and  in  the  timeliness  of  being  up-to-the- 
minute  consistent  with  the  latest  release  of  the  product. 

Increase  Design  and  Manufacturing  Coupling. 

There  are  many  opportunities  to  integrate  design  and  manufacturing.  Managing  the 
release  of  a  product  design  from  engineering  to  manufacturing  is  perhaps  the  most  impor¬ 
tant.  Automating  this  process  can  reduce  the  cycle  time  required  to  disseminate  a  released 
design  by  using  an  electronic  warehouse  as  a  bridge  between  the  designer  and  manufactur¬ 
ing.  The  system  that  provides  access  to  this  warehouse  will  include  the  product  data  man¬ 
agement  system  that  manages  the  configuration  of  the  product  data,  ensuring  the 
correctness  of  the  design  data  being  released. 

The  integration  between  engineering  and  manufacturing  can  also  be  synergistic 
with  the  automation  of  the  factory  floor.  The  design  data  from  engineering  can  be  used  to 
drive  the  CIM  programs  to  automate  control  of  factory  floor  equipment  This  being  so,  the 
factory  can  be  used  to  automatically  build  prototypes  of  a  product  by  programming  the  floor 
to  build  one  unit  from  the  prototype  design.  Through  this  process,  the  design  engineers  will 
become  familiar  with  the  capabilities  of  the  manufacturing  line.  Thus  the  engineer  can 
design  for  manufacturability,  and  can  play  an  integral  part  in  setting  up  the  manufacturing 
line  to  correctly  build  product. 

Another  point  of  coupling  between  manufacturing  and  engineering  is  an  approved 
parts  list  Engineering  may  propose  new  parts  to  be  approved  and  entered  onto  the  list  but 
manufacturing  must  approve  the  part  numbo-  and  sourcing  (for  manufacturability  and  reli¬ 
ability). 

Automate  the  Factory. 

The  manufacturing  fa(ri0i7  is  itself  an  integration  opportunity.  There  will  be  a  vari¬ 
ety  of  (heterogeneous)  numerical  control  machines,  pick-and-place  robots,  and  so  forth. 
These  can  be  controlled  by  workstations,  which  provide  “intelligence”  to  both  control  the 


machine  programming  to  achieve  one  manufacturing  step,  but  also  to  sequence  the  steps 
performed.  Thus  a  workstation  plus  a  numerical  machine  becomes  a  “brilliant  machine.” 

By  varying  the  control  sequences  in  real  time,  multiple  products  can  be  manufac¬ 
tured  on  the  same  factory  line  in  lot  sizes  as  small  as  1  or  10  units.  This  in  turn  provides  the 
flexibility  to  schedule  the  manufacturing  line  in  almost  real  time  (depending  on  the  manu¬ 
facturing  cycle  time  for  one  unit  of  product).  The  workstations  can  also  monitor  the  feed¬ 
back  from  the  numerical  machines  and  accumulate  on-line  quality  information  that  can  be 
used  to  tune  the  manufacturing  process. 

Establish  Strategic  Sourcing. 

Strategic  sourcing  refers  to  having  a  few  selected  suppliers  who  have  long-term 
relationships  with  the  company.  The  supplier  is  guaranteed  a  predictable  volume  of  on¬ 
going  business  at  a  fair  compensation,  and  the  company  has  a  partner  who  will  try  to  sup¬ 
port  the  company’s  way  of  doing  business.  This  may  extend  to  the  supplier  practicing  the 
same  kind  of  quality  program  as  the  company. 

Once  suppliers  are  selected,  the  coupling  with  manufacturing  can  be  integrated. 
EDI  can  be  used  for  purchase  orders.  Drawings  and  product  data  information  can  be  dis¬ 
tributed  electronically  to  the  supplier,  sometimes  even  with  equipment  placed  in  the  suppli¬ 
er’s  shop  at  the  company’s  expense. 

Select  Common  CAD/CAM  Tools. 

By  common  CAD/CAM  tools,  we  mean  selecting  one  vendor  for  one  type  of  tool 
and  using  that  vendor’s  tools  as  the  common  tool  of  that  type  across  the  corporation.  The 
integration  of  a  set  of  CAD  tools  into  a  cohesive  suite  is  a  significant  task.  (Some  compa¬ 
nies  specify  the  need  for  a  CAD  framework  to  simplify  this  task.)  However,  the  integration 
effort  for  one  tool  of  each  type  will  be  much  less  than  the  same  integration  task  undertaken 
with  several  tools  of  each  type. 

Use  Integrated  Software  Development  Systems. 

There  are  several  integrated  software  development  systems  for  enterprise  integra¬ 
tion  applications,  inch  ding  Texas  Instruments’  lEF  (Information  Engineering  Facility), 
Knowledgeware’s  lEW  (Information  Engineering  Workbench),  and  IBM’s  AD/Cycle. 
These  products  each  use  a  repository  or  database  to  store  a  single  description  of  data  for¬ 
mats  that  are  used  to  generate  data  structure  statements  in  the  software  developed  with  the 


B-27 


system.  Implicitiy,  applications  developed  from  such  systems  will  be  able  to  integrate  and 
exchange  data  in  a  common  data  format. 


B.  1.4.4  Replace  Legacy  Systems. 

Almost  all  companies  visited  announced  their  intention  to  replace  legacy  systems 
over  time,  several  companies  specifying  that  this  strategy  was  to  occur  during  the  next  five 
years.  Replacing  a  legacy  system  may  involve  migrating  the  data  of  the  system  to  a  new 
system  performing  a  similar  role,  or  discarding  information  stored  in  the  legacy  system’s 
format,  or  it  may  involve  keeping  one  copy  of  the  system  functioning  in  the  company’s 
archiving  facility,  in  order  to  recover  the  displaced  information. 

B.1.4.5  Other  Strategies 

Increase  warranty  service  and  manufacturing  coupling.  There  will  be  certain  kinds 
of  failures  that  will  only  be  detected  and  corrected  by  integrating  quality  information  from 
warranty  service  (i.e.,  field  service)  and  manufacturing. 

Use  customer  advisory  councils  for  feedback.  Several  companies  obtain  feedback 
from  customers  via  formal  advisory  councils.  This  enables  the  companies  to  help  fine  tune 
both  the  processes  and  the  products  in  an  integrated  enterprise. 

Use  a  single-layer  information  hitrarchy,  NeXT  Computer  contends  that  layers  are 
the  CIM  enemy  number  one.  The  assumption  here  is  that  the  corporate  network  is  a  single 
world-wide  network,  and  that  all  information  access  is  served  peer-to-peer  among  worksta¬ 
tions  and  computers  on  this  network.  TTiis  strategy  seems  synergistic  with  a  goal  of  flatten¬ 
ing  management  hierarchies  and  broadening  control  of  a  company. 

Create  object-oriented  software  tools.  Object-oriented  tools  enable  integration 
efforts  to  standardize  on  interfaces  and  minimize  the  effort  to  create  interfaces  among  the 
various  types  of  objects.  This  may  reduce  the  amount  of  work  to  achieve  integration  and 
eliminate  non-value  added  work. 

Migrate  from  mainframes  to  small  computers.  This  strategy  reflects  the  ongoing 
miniaturization  of  computing  equipment.  Using  small  computers  (e.g.,  workstations)  to 
control  the  manufacturing  line  is  an  example.  It  also  introduces  legacy  system  issues  for  the 
data  and  the  software  that  had  run  on  the  mainframe. 
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B.1J  INFORMATION  INFRASTRUCTURE 

In  this  section  we  discuss  the  technology,  both  hardware  and  software,  that  is  used 
to  support  integration  projects  today.  These  technologies  are  used  to  model,  store, 
exchange,  and  manipulate  information  as  well  as  present  information  to  the  end-users. 
There  are  also  technologies  used  in  the  software  development  of  an  integrated  system.  As 
a  group,  these  technologies  will  provide  the  infrastructure  for  the  integrated  enterprise  dur¬ 
ing  this  decade. 

The  computing  environment  for  today’s  enterprise  usually  includes  multiple  com¬ 
puting  platforms.  They  come  in  different  sizes  (mainframes,  workstations,  personal  com¬ 
puters)  from  different  vendors  (Apple  Macintcshes,  IBM  or  IBM-compatible  personal 
computers,  various  workstations,  and  mainframes).  They  run  various  operating  systems, 
from  Unix  to  MS-DOS,  from  VM  to  VMS. 

Each  corporation  has  a  world-wide  corporate  network  that  enables  each  computer 
to  be  accessed  on-line.  There  are  a  variety  of  network  protocols  (DECNet,  Domain,  Net¬ 
BIOS,  SNA,  TCP/IP).  Most  of  the  corporate  networks  are  heterogeneous,  both  in  the  sense 
that  they  use  more  than  one  network  protocol  (with  gateways  between  them)  and  in  the 
sense  that  they  connect  computers  from  multiple  vendors,  possible  running  different  oper¬ 
ating  systems  software.  There  does  tend  to  be  some  homogeneity  within  a  computer  man¬ 
ufacturer’s  own  shop.  (NeXT  Computer,  for  example,  uses  an  all  TCP/IP  network,  but  has 
Apollo  workstations  in  its  CAD  group,  a  Sequent  mainframe  in  its  information  systems 
group,  and  NeXT  workstations  for  development  systems  and  controlling  the  factory  floor.) 

An  important  value-added  networking  service  provides  EDI.  EDI  enables  paper¬ 
less,  real-time  exchange  of  purchase  orders  and  other  business  transactions  between  a  com¬ 
pany  and  its  customers  or  between  a  company  and  its  suppliers. 

The  networked  computing  environment  supports  on-line  access  to  remote  files  (files 
resident  on  remote  computers  accessed  over  the  network),  usually  using  Sun  Microsys¬ 
tem’s  de facto  standard  NFS  technology.  The  environment  also  offers  peer-to-peer  electron¬ 
ic  mail  world  wide.  There  is  technology  to  execute  a  computation  on  one  computer  while 
the  interactive  user  is  at  another  computer  (on  the  network).  This  includes  X  windows  and 
windows-oriented  user  interfaces  on  PCs  and  Mcintoshes.  In  addition  to  window  systems 
graphics  primitives,  HPGL  and  Calcomp  plotting  formats  and  the  postscript  documentation 
language  enable  the  export  wd  remote  presentation  of  drawings. 
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Much  of  the  intellectual  property  of  an  electronics  company  is  in  design  data.  This 
data  is  usually  stored  in  file  system  files,  which  may  include  optical  disk  or  CD  ROM  media 
for  large  capacity  archival  storage  of  stable  design  data. 

Data  about  design  data  (such  as  its  development  history)  and  other  operational  data 
are  kept  in  a  data  base  management  system  (DBMS).  Most  business  data  is  still  stored  using 
hierarchical  and  network  model  DBMSs  (e.g.,  information  management  systems  (IMS), 
IDMS),  the  so-called  “legacy  systems.”  Relational  DBMSs  arc  widely  used,  and  a  few  ear¬ 
ly  adopters  are  using  object-oriented  DBMSs. 

One  level  higher,  there  are  database  application  systems  (built  on  a  DBMS)  that 
manage  specific  information.  Most  companies  have  a  product  data  management  system  to 
manage  the  design  release  process  as  well  as  the  configuration  and  product  build  informa¬ 
tion.  (These  systems  arc  sometimes  called  Electronic  Vaults  or  Data  Warehouses.) 

Data  dictionaries  and  repositories  enable  applications  to  share  data,  describing  the 
access  paths  and  format  conversions  to  access  a  named  data  field.  Many  data  dictionary  sys¬ 
tems  conform  to  the  ERDS  standard. 

Two  other  important  database  applications  are  the  approved-parts  database  and  a 
pan  number  cross-reference  database  (to  convert  internal  part  numbers  to  supplier’s  part 
numbers,  or  between  one  division’s  part  numbers  and  another  division’s  part  numbers). 
Both  Tektronix  and  Texas  Instruments  mentioned  Interleaf  5’s  documentation  database, 
which  has  an  open  format  that  makes  it  easy  to  import  and  export  information. 

Workstations  deserve  special  mention  in  the  information  infrastructure  when  they 
are  used  as  device  controllers  on  the  factory  floor.  Other  pertinent  infrastructure  elements 
are  the  software  development  tools  used  to  develop  the  CIM  software,  and  the  translation 
software  that  generates  factory  control  and  numerical  machine  programs  for  a  product 
directly  from  its  CAD  design  data. 

There  were  several  other  infrastructure  technologies  mentioned  during  site  visits. 
Some  of  these  were  mentioned  frequently,  some  only  once.  We  list  selected  ones  here; 

•  Internationalized  text  strings  (c.g.,  16  bit  characters  for  Kanji) 

•  Software  development  tools  (e.g.,  lEW,  lEF,  AD/Cycle) 

•  Information  and  process  models  (e.g.,  IDEFO,  IDEFIX,  Entity-Relationship- 
Attribute  models) 

•  CAD  Frameworks  (e.g..  Falcon  Framework) 
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•  Data  locator  utilities  (e.g.,  OMG’s  Object  Request  Broker) 

•  Open  Software  Foundation’s  Distribute  Computing  Environment  (OSF/DCE) 

B.1.1  LESSONS  LEARNED 

The  electronics  sector  companies  visited  had  among  them  a  significant  base  of 
experience  in  integration  projects  and  enterprise  integration  activities.  This  experience 
yielded  a  number  of  lessons  about  success  and  failure  of  integration  projects.  We  begin  this 
section  with  a  discussion  of  the  consensus  lessons  which  were  related  to  us  by  most  of  the 
companies  visited.  Then  we  conclude  with  some  singular  lessons  that  were  each  related  by 
a  specific  company. 

Cultural  Change 

There  is  unanimous  agreement  that  overcoming  cultural  resistance  and  effecting 
cultural  change  are  the  hardest  part  of  an  integration  project.  In  preparing  for  an  integration 
project  one  should  plan  for  both  technical  changes  and  cultural  changes.  Technical  prob¬ 
lems  are  shortly  overcome,  but  cultural  change  is  a  long  drawn-out  process.  When  an  inte¬ 
gration  project  is  deployed,  one-half  of  the  benefit  comes  from  technology  and  one-half 
from  cultural  factors. 

Autonomy 

In  an  organization  *vheie  each  individual  is  encouraged  to  be  autonomous,  no  one 
person  is  an  enabler,  but  one  person  can  stop  an  integration  project  You  need  an  “approx¬ 
imate  consensus”  to  proceed.  You  must  get  and  maintain  continuous  commitment  from  all 
participants.  Start  small,  building  a  showcase  system  that  tells  its  own  success  story.  When 
extending  the  showcase  system  to  integrate  another  group,  sell  solutions  and  benefits  to  the 
new  group,  not  features  of  the  system.  Integrate  by  evolution. 

Change  and  Legacy  Systems 

Data  is  stable,  processes  change.  Hiat  is,  the  information  content  of  a  business  is 
relatively  consistent;  where  the  data  that  represents  that  information  is  acquired,  stored,  and 
used  can  change  as  the  structure  of  the  processes  that  use  it  changes.  Change  is  caused  by 
programs.  Legacy  systems  tend  to  be  owned  by  organizations  that  are  resistant  to  change. 
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Process  Modeling 

Form  shared  models  that  cross  functional  areas  or  organizations.  Make  sure  you  do 
not  partition  the  models  in  such  a  way  that  requires  redundant  processes.  Stay  away  from 
the  organizational  structure — do  not  reflect  it  in  the  process  model. 

Investing  in  People 

You  need  to  invest  the  intellectual  cost  of  putting  a  top  person  on  an  integration 
project.  Get  the  correct  experts  into  the  activities.  Empower  quality  people,  expect  a  mira¬ 
cle  (the  miracle  syndrome).  You  need  zealots  who  do  not  know  what  can’t  be  done.  You  do 
not  want  people  who  feel  restricted  by  past  practices. 

Re-engineering  the  Corporation 

When  you  look  at  a  new  system,  understand  the  current  work  process.  Identify  busi¬ 
ness  practices  that  will  have  to  change,  think  about  what  should  be  going  away,  and  figure 
out  what  it  should  be.  Ask  how  to  replace  an  old  system  rather  than  if  it  must  be  replaced. 

Sponsorship 

You  must  have  senior  management  sponsorship.  This  lesson  was  repeated  in  some 
way  by  every  company  visited.  It  should  be  a  single  person  who  is  in  the  chain  of  command 
for  every  group  involved  in  the  integration  project.  We  call  this  the  Least  Common  Man¬ 
ager  (LCM)  requirement.  The  LCM  should  be  positioned  such  that  every  middle  manager 
involved  in  the  integration  project  reports  (directly  or  indirectly)  to  her  or  him. 

Success  and  failure  stories  abound  that  reinforce  this  lesson.  One  company  reported 
a  project  that  was  started  and  failed  three  times.  The  fourth  time,  a  Director  personally 
involved  himself  in  the  project  and  it  succeeded.  Sometimes  a  none-too-subtle  nudge  is  all 
that  is  needed.  Another  company  reported  that  the  question  “who  wants  to  tell  the  Vice 
President  that  the  project  cannot  be  done?”  was  used  at  least  a  few  times  to  break  an 
impasse  in  project  meetings. 

In  another  company,  a  Director  of  one  group  and  a  Vice  President  in  another  group 
were  collaborating  on  an  integration  project  between  their  two  groups.  When  the  VP  object¬ 
ed  to  some  effects  the  project  had  on  his  operation,  the  implementation  foundered  (lack  of 
a  common  manager).  The  President  and  CEO  (the  LCM)  intervened  and  the  project  was 
completed,  to  become  one  of  the  company’s  success  stories. 
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The  sponsor  must  be  in  a  position  to  intervene  both  administratively  and  budgetari- 
ly.  Several  companies  reported  integration  projects  that  established  an  electronic  vault  or 
design  repository.  After  the  system  was  deployed,  it  went  unused  because  there  was  a  direct 
charge  for  the  space  used  by  a  program.  The  program  managers  would  not  commit  to  this 
charge,  even  though  the  cost-benefit  study  indicated  it  would  save  money  over  the  life  of 
the  project.  In  each  case  a  ^ce  President  absorbed  the  cost  of  the  vault  system  in  his  group 
budget  (charged  back  to  the  programs  as  overhead)  and  the  systems  became  utilized  and 
successes. 

In  another  situation,  funds  for  operating  an  integrated  system  were  allocated  at  too 
low  a  level  within  Divisions.  Over  a  few  years  each  Division  reduced  its  support  staff  for 
the  system,  either  by  reassignment  or  by  attrition.  When  the  once  successful  system  was 
inadequately  supported,  it  fell  into  disuse  and  was  eventually  abandoned.  Integration 
should  cross  the  corporation  and  be  a  central  function,  which  removes  it  from  local  funding 
decisions. 

Technology  and  Standards 

Technology  is  not  a  barrier  to  integration.  The  absence  of  widely  accepted  standards 
is  a  problem.  Where  standards  exist,  the  absence  of  products  that  implement  the  standards 
is  a  problem. 

Other  Lessons 

There  were  several  other  valuable  lessons  related  to  us  during  the  site  visits.  The 
following  lessons  were  each  mentioned  in  a  unique  way  by  one  company  and  we  list  them 
with  the  respective  company  in  the  following  paragraphs. 

The  following  six  lessons  are  from  Digital  Equipment  Corporation: 

( 1 )  Look  at  the  reward  systems  of  middle  managers,  which  can  reinforce  chang¬ 
ing  or  not  changing  their  organization. 

(2)  The  BRIDGE  system  succeeded  because  they  kept  bounding  the  project. 
When  it  had  been  successfully  deployed  for  one  program,  they  carefully 
took  on  new  programs,  incrementally  extending  the  project. 

(3)  The  value  of  integration  is  the  diminishing  incremental  effort  to  extend  the 
system. 

(4)  Uptime  of  the  integrated  system  is  the  most  important  user  requirement. 
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(5)  An  architecture  (i.e.,  functional  boundaries)  and  an  integration  architecture 
(function  interfaces)  should  complement  each  other. 

(6)  CIM  gets  confused  widi  automation.  S-veral  “integration  projects”  that 
were  unsuccessful  turned  out  to  be  projects  tha'  automated  business  as 
usual. 

The  following  three  lessons  are  from  Hughes  Aircraft  Company: 

( 1 )  A  multi-group  initiative  is  effective  but  less  efficient  than  a  single  organiza¬ 
tion. 

(2)  Information  systems  are  oriented  toward  the  present  (shon-term);  business 
strategies  arc  oriented  toward  the  future  (longer  term). 

(3)  Do  integration  at  data  sources. 

Two  lessons  from  IBM  are  as  follows: 

(1)  While  designing  an  integrated  system,  identify  the  integration  services  that 
serve  all  applications. 

(2)  Get  both  management  and  engineering  level  input  on  an  integration  project. 

A  lesson  from  Intel  is  that  after  investing  in  a  system,  you  must  address  how  one 

wants  to  run  the  business  using  the  system. 

Motorola  observed  that  there  is  more  payback  in  enterprise  integration  now  than 
10  years  ago,  partially  due  to  economies  of  scale. 

National  Semiconductor  related  the  lesson  to  integrate  a  multi-site  process  at  one 
site  when  it  makes  sense.  Work-in-transit  can  be  a  significant  inhibitor  to  reducing  cycle 
time. 

At  NeXT  Computer  the  Approved  Parts  List  is  owned  by  manufacturing;  they 
vetoed  35  components  in  the  first  product  NeXT  also  concluded  that  offshore  manufactur¬ 
ing  introduces  a  three-  to  six-month  delay  in  time-to-market 

Tektronix  observed  that  the  same  stream  model  (i.e.,  process  model)  exists  for  each 
engineering  discipline,  but  there  is  little  cross-talk. 

Texas  Instruments  told  us  that  a  client-server  model  has  solid  cost  benefits.  They 
also  noted  that  implementing  change  or  automation  is  quick  if  it  fits  the  current  structure, 
but  takes  a  long  time  if  it  goes  against  the  current  culture  or  facilities. 
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Westinghouse  suggests  that  integration  projects  should  evolve  via  redundancy;  that 
is,  operate  parallel  systems  until  the  integrated  sysr''m  is  accepted  and  then  cut  over  to  the 
integrated  system.  They  also  observe  that  you  should  be  prepared  to  integrate  at  any  site. 

B.2  ELECTRONICS  INDUSTRY  2001 

This  section  presents  the  state  of  the  electronics  industry  in  the  year  200 1 .  In  section 
A.  1 . 1 ,  we  discussed  four  commonly  observed  cultural  factors  among  companies  in  the  elec¬ 
tronics  sector;  technology,  competition,  innovation,  and  autonomy.  In  this  section  we  use 
these  same  four  factors  to  characterize  the  state  of  the  industry  in  the  year  2001. 

Over  the  past  10  years  technology  has  made  significant  advances  that  enabled  it  to 
better  support  integration  infrastructures.  Semiconductor  technology  continued  to  track 
Moore’s  Law.  Processors  are  eight  times  faster  and  eight  times  cheaper  than  in  1 99 1 .  Mem¬ 
ory  and  storage  devices  are  eight  times  larger  and  eight  times  cheaper  than  in  1991.  Work¬ 
stations  are  multiprocessor  systems  with  multiple  multi-media  displays.  Networks  have 
eight  times  the  capacity  and  are  eight  times  more  reliable  than  in  1991. 

Competition  continues  to  be  a  fierce  driver  among  companies  in  the  electronics 
industry.  Time-to-market  is  still  a  critical  factor  in  business  success  for  this  sector.  Product 
development  cycles,  from  conception  to  shipped  product,  are  between  two  and  three 
months.  Engineering  and  manufacturing  are  integrated  so  a  design  can  be  downloaded  to 
manufacturing  in  a  few  seconds.  Products  are  manufactured  economically  in  lot  sizes  of 
one,  and  customer-specific  products  are  a  viable  business  stiategy. 

Innovation  continues  to  be  the  key  to  remaining  competitive.  Engineering  uses 
product  specification  languages  that  are  input  to  product  synthesis  tools.  Key  intellectual 
properties  are  the  libraries  of  designs  of  reusable  components  that  are  used  by  these  synthe¬ 
sis  tools. 

Enterprises  have  been  60  to  70%  integrated  for  the  last  half  of  the  1990s,  so  inte¬ 
gration  activities  are  part  of  the  culture  in  the  industry  As  a  side-effect,  information,  both 
design  data  and  operational  data,  is  widely  shared  across  the  company  and  is  viewed  as  an 
important  corporate  resource.  However,  companies  are  still  composed  of  many  autono¬ 
mous  groups.  Entrepreneurial  projects  are  given  reasonable  autonomy  and  license  to 
achieve  product  success. 
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In  the  next  section  we  describe  a  vision  of  the  integrated  enterprise  in  2001,  and  in 
the  section  B.2.2  we  describe  the  information  infrastructure  that  will  be  necessary  to  sup¬ 
port  enterprise  integration  2001. 

B.2.1  THE  VISION 

In  the  year  2001 ,  the  major  companies  in  the  electronics  industry  are  global  compa¬ 
nies  with  engineering  and  business  operations  in  every  major  market;  North  America, 
Japan,  Europe,  Asia,  the  former  Soviet  Union,  Australia,  Africa,  and  South  America.  These 
companies  are  globally  integrated  enterprises,  transferring  and  sharing  data  around  the 
world  on  an  hourly  and  daily  basis. 

Engineers,  and  any  employee,  using  interactive  video  workstations  and  personal 
computers  routinely  open  a  window  on  their  monitor  and  dial  up  another  engineer  for  a  vid¬ 
eo  conference  that  is  displayed  in  that  interactive  video  window.  In  another  window,  all 
employees  involved  in  the  conference  simultaneously  view  the  design  or  report  that  is 
under  discussion. 

The  CAD  Framework  Initiative  has  had  success  in  defining  a  framework  standard 
for  CAD  tools,  and  both  tool  vendors  and  computer  vendors  support  the  framework  stan¬ 
dard.  The  character  of  the  standard  is  a  published  set  of  procedure  protocols  for  requesting 
services  from  the  framework  or  the  tools  registered  in  the  framework. 

The  Object  Management  Group  (OMG)  has  developed  a  similar  standard  for  pro¬ 
cedure  protocols  for  business  and  office  automation  applications.  Industry  has  led  the  effort 
to  harmonize  the  two  standards  in  order  to  support  enterprise  integration  that  spans  both 
technical  and  business  sides  of  the  enterprise. 

All  servers  register  their  functionality  with  the  object  service  broker  (the  follow-on 
to  the  OMG’s  Object  Request  Broker  of  1992)  and  describe  their  protocols  in  the  Informa¬ 
tion  and  Protocol  Encyclopedia  (a  follow-on  to  the  IRDS-2  data  dictionary). 

The  intellectual  property  of  a  company  is  composed  of  engineering  information 
about  its  products,  strategic  information  about  its  product  plans,  and  its  rule  base  of  oper¬ 
ating  policies.  This  information  is  the  major  asset  of  the  company.  The  cost  of  creating  the 
data  and  its  ongoing  value  dictate  that  it  be  on-line  and  used  in  the  operation  of  the  integrat¬ 
ed  enterprise. 
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B.22  FUTURE  INFORMATION  INFRASTRUCTURE 

The  key  technologies,  that  underlie  the  information  infrastructures  of  2001  are 
object-oriented  services,  distributed  computing.  Open  System  Interconnection  (OSI)  net¬ 
works,  documentation  tools,  database  management  systems,  and  advanced  manufacturing 
cells.  Each  of  these  is  briefly  discussed  in  the  following  paragraphs. 

Objects  provide  computational  services,  from  accessing  a  data  element  to  control¬ 
ling  a  manufacturing  cell.  An  object  owns  certain  d  ch  these  services  are  based. 

Defining  an  object  class,  with  a  published  protocol  for  accessing  its  services  is  how  facili¬ 
ties  in  one  part  of  an  enterprise  become  integrated  with  activities  in  another  part  of  the 
enterprise.  Objects  occur  everywhere  in  the  enterprise’s  distributed  network.  An  object  ser¬ 
vice  broker  locates  objects  and  transmits  service  requests  to  it. 

Distributed  computing  follows  a  client-server  architecture.  Mainframe  computers 
have  evolved  into  servers  for  data  found  in  their  voluminous  storage  capacities.  Worksta¬ 
tions  and  personal  computers  are  used  on  the  desktop  to  access  servers  and  data. 

In  the  early  part  of  1990,  OSI  network  standards  were  maturing  to  displace  propri¬ 
etary  protocols  (SNA,  NetBIOS)  and  older  standards  (TCP/IP).  The  application  layer 
offered  an  opportunity  to  add  value  and  semantics  to  networks  in  an  integrated  enterprise. 
For  example,  EDI  has  added  value  to  a  network  to  enable  exchange  of  business  forms  (pur¬ 
chase  orders,  shipping  slips)  between  suppliers  and  a  company. 

Much  of  the  operation  of  an  enterprise  is  the  processing  of  documents  (e.g.,  for 
approval)  or  disseminating  information.  Documentation  tools  are  used  to  publish  informa¬ 
tion  to  be  disseminated.  These  tools  are  also  used  to  model  various  documents  used  in  the 
enterprise,  such  as  a  purchase  order  or  a  process  specification.  An  integrated  enterprise  has 
harmonized  and  integrated  the  various  sources  of  documents. 

Database  management  system  technology  has  evolved  to  enhance  information 
usability  and  support  object  interfaces.  Relational  and  object-oriented  data  models  are 
understood  as  two  views  on  the  same  data  services.  Tables  or  spreadsheets  are  the  conven¬ 
tional  mechanism  for  accessing  and  manipulating  enterprise  data.  The  semantics  associated 
with  the  data  objects  are  supported  by  a  cell  object  in  a  cell  of  the  table.  Hybrid  databases 
have  been  developed  as  a  mechanism  to  evolve  “legacy”  databases,  such  as  those  contained 
in  older  hierarchical  or  relational  database  management  systems,  into  the  newer  database 
servers. 
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On  top  of  documentation  tools  and  database  management  systems,  enterprise  inte¬ 
gration  vendors  build  product  data  management  tools  and  integrated  resource  management 
tools.  Using  resource  management,  the  integrated  enterprise  processes  orders  and  purchas¬ 
es;  schedules  inventory  deliveries,  manufacturing,  staff;  and  supports  financial  activities 
necessary  for  the  operation  of  the  enterprise. 

Advanced  manufacturing  cells  are  modular,  capable  of  efficiently  manufacturing 
various  products  in  lot  size  one.  They  have  workstations  as  controllers  so  that  significant 
computation  can  be  performed  locally  (e.g.,  for  quality  control)  and  the  manufacturing  con¬ 
trol  can  be  compiled  from  designs  by  computations  on  the  workstations. 

B.3  ISSUES  AND  BARRIERS 

In  this  section  we  discuss  issues  involved  in  implementing  enterprise  integration 
today  and  barriers  that  might  prevent  the  electronics  industry  from  meeting  the  projected 
vision  of  enterprise  integration  2001. 

As  can  be  seen  from  the  “high  water  mark”  integration  scenario  (see  section 
B.  1.3.1),  current  technology  is  not  the  barrier  to  achieving  greater  enterprise  integration  in 
1991.  If  the  maxim  “be  all  that  you  can  be”  is  applied  by  the  electronics  industry  to  inte¬ 
gration,  it  will  do  a  lot  of  building  on  the  technology  and  information  infrastructure  avail¬ 
able  today. 

Although  technology  is  not  a  banier  to  integration,  the  absence  of  widely  accepted 
standards  is  a  problem.  Where  standards  exist,  the  absence  of  products  that  implement  the 
standards  is  a  problem. 

It  has  been  observed  several  times  in  dtis  report  that  cultural  issues  are  more  than 
half  of  the  problem.  An  integrated  enterprise  seeks  to  achieve  business  practices  that  are 
globally  optimized  across  the  enterprise.  In  most  optimization  problems,  the  global  opti¬ 
mum  is  not  obtained  by  combining  a  set  of  steps  that  are  local  optima.  One  cultural  issue  is 
the  mismatch  of  goals  between  the  enterprise  and  the  profit  and  loss  (P&L)  center,  when 
the  enterprise  is  trying  to  optimize  through  integration  and  the  P&L  center  is  working  to 
optimize  its  net  profit  To  the  P&L  center,  integration  is  likely  to  seem  to  be  an  expensive 
intrusion. 

Another  potential  cultural  mismatch,  at  a  higher  level,  is  how  one  views  the  enter¬ 
prise  when  planning  integration.  There  is  at  least  an  operational  view  and  a  financial  view, 
perhaps  a  distinct  business  view  as  well.  The  chief  operating  officer  may  want  to  integrate 
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engineering,  manufaciuring,  and  field  service,  while  the  chief  financial  officer  may  want  to 
integrate  manufacturing,  budgeting,  and  finance.  Today,  most  integration  activities  are 
strictly  in  the  realm  of  operations.  The  point  is  that  to  plan  and  carry  out  enterprise  integra¬ 
tion  projects,  the  sponsor  should  have  defined  the  Enterprise  as  it  is  being  viewed  for  these 
projects  and  the  goals  of  integration. 

The  need  to  re-engineer  the  corporation  was  cited  repeatedly  in  our  site  visits.  The 
task  of  re-engineering  the  way  you  do  business  will  spread  cultural  issues  as  the  wind 
spreads  dandelion  seeds.  One  way  to  manage  the  re-engineering  task  is  to  state  as  rigorous¬ 
ly  and  formally  as  possible  the  goals  and  objectives  of  the  integration  activity.  Then  devel¬ 
op  a  process  model  of  the  enterprise  that  is  structured  to  be  aligned  with  the  enterprise  as 
expressed  in  these  goals  and  objectives.  There  may  be  a  threshold,  measured  in  the  com¬ 
plexity  of  the  part  of  the  enterprise  being  integrated,  below  which  integration  guided  by 
intuition  can  succeed,  and  above  which  more  formal  planning,  such  as  developing  the 
enterprise  process  model,  is  required.  The  role  of  process  modeling  in  enterprise  integration 
1991  is  an  open  issue. 

Legacy  systems  have  also  been  referred  to  consistently  in  our  interview  visits.  To 
some  extent  legacy  systems  are  an  understood  issue,  but  each  legacy  system  dealt  with  is 
an  open  issue  until  it  is  decided  how  that  legacy  system  will  be  incorporated  into  the  inte¬ 
grated  enterprise. 

The  last  issue  we  mention  here  is  the  role  of  integrated  software  development  sys¬ 
tems.  Various  systems  (AD/Cycle,  lEF,  lEW)  have  been  reported  during  site  visits.  These 
systems  use  repositories,  encyclopedias,  and  shared  databases  for  the  applications  they  gen¬ 
erate,  and  they  do  enforce  the  model  of  the  enterprise  as  specified  to  the  development  sys¬ 
tem.  The  question  of  the  necessity  of  an  integrated  software  development  system  remains 
unresolved. 

In  the  remainder  of  this  section  we  discuss  four  barriers  to  enterprise  integration 
2001.  The  four  barriers,  electronic  signatures,  standards,  adaptive  interfaces,  and  database 
migration,  all  have  underpinnings  in  technology  and  require  some  technical  progress  before 
they  are  overcome.  Problems  that  have  only  a  cultural  basis  are  discussed  in  the  issues 
above;  perhaps  some  of  them  are  actually  barriers  to  successful  integration.  Although  the 
discussion  of  barriers  will  focus  on  the  technical  components,  we  recognize  that  with  each 
of  these  technology-based  barriers  there  is  a  cultural  component  as  well. 
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Electronic  Signatures 

A  characteristic  of  an  integrated  enterprise  is  that  paper  tends  to  be  replaced  by  elec¬ 
tronic  media  for  information  dissemination.  We  noted  that  even  where  electronic  transmis¬ 
sion  of  drawings  is  implemented,  one  paper  signature  copy  is  required  in  the  approval 
process,  primarily  for  legal  purposes. 

There  are  other  activities,  EDI  transactions  for  example,  that  require  authentication 
of  the  sender’s  identity.  EDI  provides  authentication  services  that  are  essentially  based  on 
mutual  trast  between  each  of  the  parties  to  the  transaction  and  the  EDI  service  provider. 
This  is  why  EDI  uses  a  value-added  networic  service  and  not  just  simply  dial-up  network 
connections. 

There  are  several  public  key  encryption  methods,  some  even  becoming  standards 
that  could  solve  the  electronic  signature’s  technical  requirements,  so  perhaps  this  is  a  cul¬ 
tural  barrier.  The  two  steps  to  remove  this  barrier  are  to  have  widely  available  encryption 
imj^enientations  and  some  established  laws  or  rulings  that  electronic  documents  with  valid 
electrc  nic  signatures  have  proper  and  acceptable  legal  standing.  It  would  be  preferable  that 
the  ennyption  implementation  be  available  as  compatible  shrink-wrap  software  for  all  of 
the  maior  computer  vendor’s  products. 

Standaris 

A  second  barrier  is  involves  the  lack  of  effective  standards.  Standards  are  intended 
to  remove  barriers  to  communication  and  integration,  but  many  barriers  remain  even  with 
several  standard:  that  attempt  to  address  the  barrier. 

One  problem  stems  from  the  standards  process  itself.  Standards  tend  to  gain  approv¬ 
al  by  building  consensus,  and  it  is  easiest  to  get  agreement  on  common  technology  and 
common  practice.  Many  star.idards  seem  to  have  emerged  as  the  least  common  denominator 
of  potentially  conflicting  practices.  IGES  is  one  example.  IVo  comments  made  during 
interview  visits  were  “IGES  is  not  enough”  and  “the  important  stuff  gets  through.”  In  the 
latter  case  the  necessary  “unimportant  stuff”  was  sent  in  separate  files  using  proprietary  for¬ 
mats  to  complete  the  design  description. 

Standards  tend  to  address  niche  problems.  For  example,  EDI  defines  a  limited  num¬ 
ber  of  document  formats  that  it  can  accept  and  deliver.  One  company  said  that  we  need 
“harmonization  of  office  automation  with  engineering”  in  the  EDI  standards.  Another 
example  is  Product  Data  Management.  There  is  no  common  fo-  for  a  bill-of-materials 
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or  jvoduct  configuration  that  is  used  in  electronic  engineering,  mechanical  engineering,  and 
software  engineering  (i.e.,  ECAD.  electronic  CAD;  MCAD,  mechanical  CAD;  and  CASE, 
computer-aided  software  engineering). 

Another  problem  is  that  we  need  products  that  implement  standards.  Part  of  this  sto¬ 
ry  is  that  the  standards  development  process  is  much  slower  than  the  product  development 
process  (years  versus  months).  This  leads  to  companies  offering  products  with  so-called 
proprietary  or  de  facto  standards.  These  work  fine  when  all  of  one’s  tools  come  from  a  sin¬ 
gle  vendor,  but  they  may  not  remove  this  barrier  to  integration  in  a  heterogeneous  environ¬ 
ment 

Adaptive  Interfaces 

Integration  depends  on  the  ability  to  acquire  and  interpret  shared  data.  By  “inter¬ 
pret”  we  mean  to  use  the  data  in  the  manner  in  which  it  was  intended  to  be  used.  Object- 
oriented  technology  uses  published  interface  protocols  to  specify  what  data  is  available 
from  an  object  and  how  it  may  be  used.  Protocols  also  specify  what  services  are  provided 
on  the  object,  and  what  are  the  semantics  of  those  services.  Procedurally  oriented  standards 
like  those  emerging  from  the  Object  Management  Group,  the  CAD  Framework  Inii.  .five, 
and  PDES  (in  its  application  program  interface  (API)  work)  provide  these  protocol  speci¬ 
fications  for  specific  classes  of  applications. 

A  barrier  arises  when  different  objects,  conforming  to  different  standards  or  offer¬ 
ing  only  proprietary  interface  specifications,  offer  similar  services  through  different  proce¬ 
dures.  A  meta-object  model,  which  might  also  be  called  an  adaptive  interface  model,  would 
provide  a  description  of  the  services  offered  by  an  object  and  how  to  access  those  services 
in  an  interpretive  way.  In  this  way,  if  a  system  wanted  the  “phone  home”  service  from  an 
ET^-type  object,  it  wauld  access  the  description  of  an  ET  class  of  objects,  determine  that  it 
had  a  “phone  home”  procedure,  and  obtain  a  description  of  the  number,  type,  and  sequence 
of  parameters  required  to  invoke  the  service.  Similarly,  if  a  program  wanted  the  “phone 
home”  service  from  a  student-type  object,  it  would  obtain  the  appropriate  information 
about  a  student  class  of  objects.  These  descriptions  are  obtained  using  a  “meta-object” 
interface  protocol  that  specifies  how  to  obtain  information  from  an  object  class  dictionary 
about  specific  object-level  interface  protocols  and  how  to  invoke  those  object  interfaces 
through  a  genoic  (higher-level)  procedure  call. 
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Database  Migration 

The  legacy  database  issue  introduces  another  technical  barrier,  that  of  data  migra¬ 
tion.  Technologically,  we  know  how  to  access  data  in  an  IMS  database,  and  we  know  how 
to  encapsulate  or  put  a  wrapper  around  an  IMS  database  that  provides  services  like  an  SQL 
database.  However,  neither  these  approaches  nor  converting  a  large  IMS  database  to  a  (for 
example)  DB2  database  are  desirable  technical  solutions  for  dealing  with  a  legacy  database. 

If  we  put  a  wrapper  around  a  legacy  database  and  access  a  data  element,  call  it  X, 
then  we  have  to  pay  the  cost  of  processing  a  query  that  returns  X.  If  we  need  to  access  X 
10  times,  we  pay  10  times  the  cost  of  processing  the  query.  Since  the  cost  of  a  query, 
through  a  >vrapper,  against  an  IMS  database  is  much  more  than  the  expected  cost  of  the 
equivalent  query  against  a  DB2  database,  it  would  be  a  better  strategy  to  query  the  IMS 
database  once,  store  the  resulting  data  element  X  into  the  DB2  database,  and  for  the  next 
nine  accesses  to  X,  query  the  DB2  database. 

This  is  similar  to  incremental  database  reorganization  or  data  nugration.  (The  alter¬ 
native  to  incremental  reorganization  is  total  reorganization.)  Typically  in  an  IMS-like  data¬ 
base,  incremental  reorganization  (if  it  is  done  at  all)  is  done  on  a  segment  or  record-type 
basis,  that  is,  to  convert  all  the  records  of  the  same  type  at  the  same  time.  In  the  strategy 
outlined  previously,  conversion  would  occur  on  a  per  record  basis  (one  record  at  a  time).  In 
an  object-oriented  database,  object-at-a-time  (i.e.,  record-at-a-time)  type  migration  has 
been  studied  and  can  be  done.  But  an  object-oriented  database  management  system  has  type 
meta-data  about  each  object  that  is  not  present  in  an  IMS  database.  So  we  have  no  known 
mechanism  to  keep  track  of  which  records  have  been  migrated  and  which  have  yet  to  be 
migrated.  This  is  the  research  problem  that,  when  solved,  will  remove  the  barrier  of  data 
model  migration. 

B.4  RECOMMENDATIONS 

In  this  section  we  present  five  specific  recommendations  to  the  electronics  industry. 
We  conclude  with  a  discussion  of  the  structure  of  standards  organization. 

Recommendation  1.  Define  enterprise  integration  first.  Since  enterprise  integra¬ 
tion  is  not  something  that  would  be  the  same  in  every  situation,  define  what  you  mean  by 
integration  within  your  enterprise  before  starting  on  integration  projects.  By  setting  a  stable 
context  for  an  integration  project  and  understanding  what  you  hope  to  accomplish  with  that 
project,  you  can  improve  your  focus  and  expectations  for  a  successful  project. 
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Recommendation  2.  Re«engineer  management’s  mindset,  then  re-engineer  the 
corporation.  It  appears  to  be  good  integration  practice  to  re-engineer  the  part  of  the  corpo¬ 
ration  being  integrated.  To  be  successful,  this  requires  the  sponsorship  of  a  high-level  man¬ 
ager.  Since  integration  projects  are  at  least  50%  cultural,  start  your  re-engineering  work  on 
the  mindset  of  your  sponsor  and  his  or  her  immediate  subordinates. 

Recommendation  3.  Learn  by  doing.  If  your  goal  is  to  integrate  the  enterprise, 
start  with  a  useful,  small,  first  step.  If  an  integration  project  is  staggering,  bound  (reduce) 
its  scope  and  achieve  a  focused  success.  From  a  basis  of  one  successful  project,  incremen¬ 
tally  extend  the  system  to  include  another  group.  Consolidate  the  larger  system  and  make 
it  successful  before  growing  again. 

Recommendation  4.  Support  government  action  to  give  electronic  signatures 
legal  standing. 

Recommendation  5.  Proactively  support  promising  standards  organizations. 
The  output  of  a  standards  activity  is  commensurate  with  the  quality  of  its  input.  Don’t 
expect  great  and  useful  standards  to  just  happen.  There  are  really  two  ways  to  participate 
in  a  standards  effort,  actively  or  observing.  Active  participation  requires  that  people  do 
their  homework  between  meetings,  perhaps  spending  half-time  or  more  between  going  to 
meetings,  and  technical  preparations  (“homework”).  Observing  “just”  requires  attending 
meetings.  For  most  companies,  it  is  a  better  investment  to  actively  participate  in  a  few  stan¬ 
dards  efforts  (with  several  people  active  in  each)  than  to  “monitor”  many  efforts  by  sending 
one  observer  to  each. 

To  support  enterprise  integration,  a  standard  must  be  useful  and  capable  of  servicing 
a  complete  task.  This  requires  that  the  emerging  standard  be  reviewed  for  usefulness  in 
addition  to  consensus.  Trying  to  quickly  build  a  consensus  can  lead  to  identification  of  the 
common  functionality  among  various  approaches  to  a  standard.  It  might  be  infeasible  to  use 
the  “least  common  denominator”  without  technical  extensions. 

A  standards  organization  must  have  effective  technical  leadership.  Most  standards 
activities  participants  are  volunteers  who  tend  to  work  on  the  aspect  of  the  standard  that  is 
their  particular  interest  This  can  be  very  limiting,  initiating  too  many  technical  thrusts, 
each  without  the  critical  mass  needed  to  complete  any  one  of  them.  One  company  can  put 
critical  mass  into  a  working  group,  providing  fac/o  leadership,  or  the  standards  organi¬ 
zation  can  have  a  strong  technical  executive.  This  technical  executive  may  be  a  technical 
director  who  is  on  the  full-time  staff  of  the  standards  organization  (like  the  Object  Manage- 


mcnt  Group),  it  may  be  an  executive  committee,  or  it  maybe  contracted  out  to  a  company 
to  provide  the  leadership  (as  occurred  with  the  development  of  VHDL). 

The  technical  executive  should  establish  his  or  her  own  vision  for  the  target  stan¬ 
dards,  in  order  to  provide  leadership.  On  occasions  he  or  she  must  have  the  ability  to  tell  a 
volunteer  that  her  or  his  efforts,  although  interesting,  are  not  aligned  with  the  current  stan¬ 
dards  activities  and  to  reassign  the  person  to  a  task  that  is  needed  to  get  closure  on  the  stan¬ 
dard.  Companies  supporting  a  specific  standards  committee  should  consider  assigning  a 
half-time  or  full-time  technical  contributor  to  die  organization. 

In  addition,  some  standards  organization  have  a  sustaining  level  of  membership 
whose  fees  provide  the  primary  support  for  the  organization  (e.g.,  CFI  or  PDES,  Inc.). 
Companies  who  judge  that  they  have  a  vested  interest  in  obtaining  an  approved  standard 
should  participate  in  the  standards  organization  at  this  level.  These  sustaining  companies 
should  bring  technology  to  the  table,  to  leverage  the  standards  development  effort.  They 
should  also  require  that  reasonable  performance  goals  be  met,  with  precise  annual  objec¬ 
tives,  project  schedules,  stated  milestones,  and  acceptance  criteria  commensurate  with  the 
level  of  resources  provided  by  the  sustaining  members. 

B.5  LIST  OF  COMPANIES  VISITED 

( 1 )  Digital  Equipment  Corporation 

(2)  Enterprise  Integration  Technology  Inc./Stanford  University 

(3)  Hughes 

(4)  IBM 

(5)  Intel 

(6)  Motorola 

(7)  National  Semiconductor 

(8)  NeXT  Computers 

(9)  Tektronix 

(10)  Texas  Instruments 

(11)  Westinghouse 
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APPENDIX  C.  AUTOMOTIVE  INDUSTRY  RATIONALE 


C.1  AUTOMOTIVE  INDUSTRY  1991 

The  purpose  of  this  report  is  to  document  the  state  of  enteiprise  integration  as  it 
exists  today  in  the  automotive  industry,  create  a  vision  of  how  it  might  look  in  the  year 
2001,  and  determine  the  information  infrastructure  necessary  to  support  that  vision. 

The  automobile  is  an  integration  of  many  complex  systems.  Mass  manufacturing 
techniques  for  the  automobile  make  it  a  very  accessible  appliance  for  most  people  in  devel¬ 
oped  countries.  Due  to  the  complexity  of  both  product  and  process,  the  production  of  auto¬ 
mobiles  can  be  considered  the  most  complex  industrial  undertaking  in  the  developed  world. 
While  a  few  products  may  be  more  complex,  none  engage  the  industrial  infrastructure  as 
does  the  automobile.  Further,  its  size  ensures  that  advances  made  in  this  industry  will 
receive  interest  from  all  sections  that  serve  manufacturing  and  the  wider  economy.  For 
these  reasons,  it  is  important  that  the  automotive  industry  be  a  driver  of  an  information 
infrastructure  backbone  for  enterprise  integration. 

The  report  presents  the  automotive  business  rationale  for  new  information  infra¬ 
structures  to  support  enteiprise  integration.  It  has  five  sections:  Automotive  Industry  1991, 
Automotive  Industry  2001,  Issues  and  Barriers,  Recommendations,  and  a  List  of  Compa¬ 
nies  \^sited.  The  observations,  conclusions,  and  visions  discussed  in  this  report  are  based 
on  site  visits  and  roundtable  discussions  with  automotive  executives  and  consultants  who 
know  die  automotive  enterprise.  Additional  information  was  taken  from  documents  listed 
in  the  references,  and  the  experience  of  the  professional  staff  at  Industrial  Technology  Insti¬ 
tute  (ITI). 

C.1.1  INTRODUCTION:  STATE  OF  COMPETITION 

Most  current  studies  suggest  that  the  U.S.  automotive  industry  is  lagging  signifi¬ 
cantly  behind  the  Japanese  and  perhaps  the  European  automotive  industry  in  almost  every 
critical  measurement:  cost,  quality,  and  time-to-market  (TTM).  For  the  last  two  years 
(1989-1991),  the  Honda  Accord  has  been  the  highest  selling  automobile  in  North  America. 


On  the  coasts  of  North  America,  American  cars  are  becoming  the  exception  rather  than  the 
rule. 


In  a  recent  book  by  Kim  Clark  and  Takahiro  Fujimoto,*  comparative  statistics  on 
the  engineering  hours  and  elapsed  time  needed  to  produce  a  small  car  with  two  models  were 
published  (see  Table  C-1). 

Table  C-1.  Auto  Engineering  and  Schedule  by  Locale 


Japan 

USA 

Europe 

Higb 

Volume 

Europe 

Speciality 

Engineer  hours 
(millions) 

1.7 

3.2 

3.0 

3.0 

Lead  time  adjusted 
(months) 

45 

60 

57 

63 

Japan  clearly  has  the  advantage,  and  strikingly  so,  in  both  cost  and  time.  The  same 
repon  lists  only  2  American  vehicles  in  the  top  15  in  terms  of  a  total  product  quality  index. 
These  figures  may  not  be  totally  inclusive,  but  the  trend  is  clear. 

Chrysler,  which  was  number  three  in  the  world  market,  is  now  fighting  for  survival. 
It  has  been  marketing  and  selling  cars  built  on  its  K  frame  for  the  last  10  years.  Its  big  seller 
has  been  its  popular  minivan.  They  are  currently  trying  to  refinance  some  of  their  opera¬ 
tions  because  of  a  current  and  projected  cash  flow  problem.  Similarly,  neither  Ford  nor 
General  Motors  (GM)  has  made  a  profit  on  the  North  American  automotive  business  in  the 
last  few  years.  GM,  which  only  a  few  years  ago  was  concerned  about  antitrust  legislation 
because  it  controlled  significantly  more  than  50%  of  the  domestic  market,  now  has  about 
35%  of  the  market  and  has  been  closing  plants  the  last  several  years. 

Until  the  late  1970s,  GM  was  not  only  its  own  competition  but  also  its  own  supply 
base.  The  GM  Oldsmobile  division  looked  upon  the  Pontiac  and  Buick  divisions  as  its  com¬ 
petition  in  the  large  family-car  market  There  were  over  15  divisions  of  GM  supplying  over 
55%  of  the  valued  added  to  the  GM  family  of  vehicles.  These  were  independent  competing 
businesses  which  would  not  consider  sharing  processing  ideas  or  information  systems  with 


’  Clark.  K.B.  and  Fujimoto,  T.  Product  Development  Performance.  Boston;  Harvard  Business  School  Press, 
1991. 
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one  another,  or  sharing  cost  information  with  a  car  division  to  which  they  supplied  parts. 
As  a  result,  a  major  player  in  the  world-wide  automotive  business  had  trouble  communi¬ 
cating  internally  with  its  over  200  plants,  let  alone  with  the  rest  of  the  enterprise.  Corporate 
standards  for  internal  communications  (CISCO)  were  put  in  place  during  the  mid-1970s  in 
an  effort  to  correct  this  problem. 

During  the  1980s,  GM  has  moved  from  a  corporation  that  is  its  own  supply  base  to 
a  corporation  that  increasingly  out  sources  engineering  services,  design  services,  and  parts 
supply.  This  transition  has  a  great  influence  on  the  diminishing  effect  of  its  internal  com¬ 
munications  standards.  GM  now  finds  that  a  large  part  of  its  business  involves  conununi- 
cating  with  companies  that  are  not  part  of  its  communication  network  and  who  do  not  use 
the  GM  standards  for  communications.  As  a  result,  GM  imposes  its  standards  on  large,  or 
Srst  tier,  suppliers,  and  forces  smaller  suppliers  of  services  and  parts  into  a  sub-tier  position. 
This  evolution  is  not  exclusive  to  GM  as  Ford  and  Chrysler  are  also  outsourcing,  forcing 
their  own  standards  on  first-tier  suppliers,  and  rationalizing  the  supplier  base,  forcing  the 
smaller  companies  into  sub-tier  supplier  positions. 

Table  C-2  lists  the  key  sections  within  the  auto  industry  with  which  the  original 
equipment  manufacturers  (OEMs)  must  communicate  directly  or  indirectly  in  designing 
and  building  cars.  The  table  shows  only  a  subset  of  the  many  industries  involved  in  the  auto 
industry.  Many  players,  including  both  large  and  small  companies,  are  involved.  Interaction 
in  goods,  services,  and  information  among  these  companies  is  essential  to  a  successful 
automotive  enterprise. 

The  automotive  enterprise  is  made  up  of  thousands  of  facilities.  These  facilities 
assemble  vehicles,  manufacture  parts,  make  tools  and  dies,  engineer  vehicles  and  sub¬ 
systems,  design  and  manufacture  machine  tools,  sell  and  service  vehicles,  and  sell  replace¬ 
ment  parts.  In  Michigan  alone,  there  are  between  SOO  and  600  small  manufacturers  and 
dealers  who  are  part  of  this  total  enterprise.  The  technology  gap  between  the  OEMs  and  the 
smallest  of  these  suppliers  is  significant  The  larger  firms  use  state-of-the-art  computer- 
based  manufacturing  technology,  while  many  of  the  smaller  firms  function  completely 
manually  with  perhaps  a  single  personal  computer  (PC)  for  accounting  and  communica¬ 
tions.  A  recent  study^  on  small  tool  and  die  manufacturing  in  Michigan  concluded  that  tool- 

^  Fleischer,  MJF,  Phelps,  T.A.  and  Easing,  M.  CADtCAM  Data  Problems  and  Costs  in  the  Tool  and  Die 
Industry.  Final  Report  of  the  Industrial  Technology  Institute  and  the  Detroit  Chapter  of  the  National  Tool¬ 
ing  and  Machining  Association,  1991  (TTI  Report  CR-91-03). 


TaMe  C-2.  Key  Sectors  Within  the  Automotive  Industry. 
AUTOMAKERS 

Assembly  plants  (vehicle,  engine,  and  transmission) 

Captive  parts  plants 
Corporate  functions 

Advanced  engineering 
Product  planning 
Marketing 
Financial 

INDEPENDENT  ENGINEERING  FIRMS 

MACHINE  TOOL  MAKERS 

TOOL  AND  DIE  MAKERS 

PARTS  SUPPLIERS 
Stamping 
Plastics 
Others 

CONTRACT  MACHINE  SHOPS 
MATERIAL  PROVIDERS 

ing  and  die  costs  could  be  reduced  as  much  as  2U%  through  improved  inf  ormation  transfer 
between  the  OEMs  and  the  many  layers  of  suppliers. 

The  following  table  (Table  C-3)  and  figure  (Figure  C- 1 )  show  just  some  of  the  tasks 
and  responsibilities  that  must  be  coordinated  to  design  a  minor  change  to  a  vehicle.  The 
information  that  must  accompany  the  tasks  goes  through  a  series  of  uncoordinated  manual 
and  computerized  information  systems.  This  chart  demonstrates  the  complexity  of  the 
design  process  which  is  described  in  greater  detail  in  the  next  section. 

This  simplified  description  illustrates  some  of  the  complexity  in  the  design  process. 
It  leaves  out  the  continuing  interactions  that  occur  as  production  begins,  and  eventually  as 
replacement  part  production  commences.  These  phases  require  additional  coordination 
among  the  players  in  the  process. 

C.1,2  EXAMPLES  OF  PROBLEMS  IN  THE  DESIGN  PROCESS 

The  following  list  gives  some  of  the  most  common  problems  in  the  design  process, 
focusing  on  those  most  relevant  to  enterprise  integration  activities.  These  are  not  the  only 
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Table  C-3.  Steps  in  the  Automotive  Design  Process 
(A  Minor  Product  Change) 


DFA  Design  for  Assembly 

DFM  Design  for  Msnufaccuhng 

OEM  Origins}  Equipment  Minofscturers 


problems  associated  with  U.S.  automotive  manufacturing,  but  since  7U  to  80%  of  the  vehi¬ 
cle  costs  are  determined  during  the  design  process,  they  are  good  examples  of  the  types  of 
problems  encountered.  Although  technical  problems  exist,  the  underlying  problems  are 
more  business-oriented.  As  we  note  later  in  our  recommendations,  addressing  these  prob¬ 
lems  requires  commitment  at  the  upper  levels  of  the  enterprises  involved. 

•  Companies  are  unable  to  share  product  data  electronically. 

•  There  is  poor  communication  between  parties  in  tlie  process. 

•  Reward  systems  do  not  encourage  reusable  designs. 

•  True  sharing  of  information  is  difficult,  due  to  lack  of  universal  technology  and 
management  systems  to  support  their  use. 


Figure  C-1.  Information  Flow  in  the  Automotive  Design  Process 
(A  Minor  Product  Change) 


•  OEMs  still  treat  suppliers  unfairly.  For  example,  suppliers  are  brought  in  too 
late  and  without  requisite  information. 

From  a  technical  standpoint,  CAD  is  the  most  important  technology  in  the  design 
process.  However,  addressing  the  problems  identified  below  requires  not  only  advances  in 
technical  capabilities  but  changes  in  the  business  environment  that  will  allow  the  technical 
solutions  to  flourish.  Enterprise  integration  must  address  each  of  these  areas,  even  when  it 
is  dealing  with  technical  areas  such  as  CAD. 

•  Use  of  both  CAD  and  manual  design  methods  throughout  the  process  adds  time 
and  complexity. 

•  There  is  difficulty  sharing  CAD  data  among  players. 

•  The  multiplicity  of  CAD  systems  in  use  confounds  data  translation  efforts. 

•  CAD  libraries  are  often  proprietary,  leading  to  the  re-creation  of  existing 
designs. 

In  addition  to  those  problems,  a  variety  of  issues  inherent  in  the  supplier-customer 
relationship  frustrates  the  product-development  process: 

•  Emphasis  on  delivered  price  starves  supplier  firms,  thus  making  it  difficult  for 
them  to  invest  in  needed  technology  and  training. 

•  Lack  of  ongoing  communication  between  those  who  design  parts,  those  who 
make  dies,  and  those  who  make  parts  requires  constant  adjustment  of  dies  and 
parts  throughout  the  process. 

•  Dies  are  often  “overengineered”  to  account  for  outdated  equipment  or  poorly 
trained  workforce,  thus  adding  cost  and  time. 

•  Many  firms  lack  accurate  production  data  from  customers,  thus  frustrating 
attempts  to  produce  on  a  JIT  basis. 

•  Major  customers  sometimes  cancel  or  delay  design  projects  due  to  financial 
constraints. 

During  the  late  1970s  and  early  1980s,  when  the  problems  of  competition  became 
apparent,  management  blamed  the  major  problems  on  the  high  cost  of  labor  or  the  dollar- 
to-yen  exchange  rates.  We  now  recognize  the  problem  to  be  many-faceted,  with  labor  and 
the  exchange  rates  being  very  minor  contributors.  The  major  problems  are  in  the  areas  of 
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planning,  execution,  culture,  organization,  and  information  sharing  across  the  many  parts 
of  the  enterprise. 

In  recent  years,  the  Big  Three  (GM,  Ford,  and  Chrysler)  have  recognized  the 
importance  of  early  communication  between  themselves  and  their  suppliers  (including 
links  between  their  own  divisions  and  other  parts  of  the  corporation  that  drive  the  design 
and  production  process).  The  result  has  been  the  establishment  of  product  development 
teams  and  long-term  relationships  between  customer  and  supplier.  The  OEMs  have  been 
more  successful  at  utilizing  internal  or  inter-departmental  product  development  teams. 
There  are  still  weaknesses  in  the  links  to  the  supplier  members  of  the  team.  Communication 
typically  consists  of  the  OEMs  telling  the  suppliers  what  they  think  they  need  to  know.  The 
communication  is  rarely  two-way.  The  suppliers  cannot  give  feedback  or  implement 
change  in  the  design  process  in  any  way.  Product  development  groups  exist,  but  they  gen¬ 
erally  pass  information  rather  than  share  information  or  even  more  to  the  point,  use  infor¬ 
mation.  Another  constraint  to  the  communications  process  is  that  suppliers  are  not 
effectively  connected  to  the  automated  information  systems  that  the  OEMs  have  imple¬ 
mented. 

C.13  STATE  OF  INTEGRATION  1991 

Many  now  believe  that  some  of  the  foregoing  problems  can  be  solved  by  imple¬ 
menting  a  concept  called  enterprise  integration.  Enterprise  integration  refers  to  a  condition 
in  which  accurate  and  timely  information  flows  smoothly  within  a  company,  and  between 
the  company  and  its  suppliers,  customers,  and  partners.  In  the  integrated  enterprise,  all  parts 
of  the  organization  work  cooperatively  toward  the  satisfaction  of  common  goals  and  objec¬ 
tives.  Systems,  procedures,  and  technologies  are  coordinated  to  minimize  waste.  The  value 
of  enterprise  integration  lies  in  its  potential  to  help  companies  speed  the  development  of 
better  products  and  services,  capitalize  on  business  opportunities,  and  reduce  operating 
cost 

Enterprise  integration  is  a  broad  concept  that  sets  the  technology  of  integration 
within  the  context  of  the  organization,  the  culture,  and  the  work  force.  Enterprise  integra¬ 
tion  has  several  characteristics: 

•  Approaches  such  as  concurrent  engineering,  QFD,  Design  for  Manufacturing, 
CPI,  and  TQM  are  used  across  the  organization  to  achieve  common  strategies, 
goals,  and  objectives. 
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•  The  capabilities  and  relationships  of  people,  processes,  and  tools  are  employed 
to  optimize  the  use  of  critical  resources  to  meet  corporate  goals  and  objectives. 

•  The  redundancy  of  data,  processes,  and  tools  to  perform  a  process  is  minimized. 

•  The  data,  processes,  and  tools  needed  to  perform  a  function  are  readily  avail¬ 
able. 

•  Measurement  and  reward  systems  are  designed  and  implemented  to  encourage 
cooperation  and  team  efforts  to  achieve  corporate  goals  and  objectives. 

•  Clear,  understandable  strategies,  business  plans,  and  goals  are  visible  and  com¬ 
municated  to  all  parts  of  the  organization. 

•  Organizational  structures  are  designed  to  facilitate  cooperation  and  timely  deci¬ 
sions  within  the  enterprise. 

While  many  aspects  of  enterprise  integration  focus  on  people  and  organizational 
issues,  one  of  the  necessary  building  blocks  is  an  information  infrastructure  for  integration 
in  place  among  all  parts  of  the  organization,  including  the  partners. 

All  U.S.  automotive  OEMs  have  programs  in  place  today  to  integrate  their  informa¬ 
tion  and  business  systems.  They  realize  that  the  information  they  use  to  run  and  coordinate 
their  business,  both  in  the  short-term  and  long-term,  is  taken  from  their  information  sys¬ 
tems.  Today,  in  the  North  American  OEMs,  the  same  information  resides  in  several  differ¬ 
ent  databases  which  are  updated  at  different  times  from  different  sources.  This  results  in 
uncoordinated  planning,  engineering,  manufacturing,  and  scheduling  systems. 

Companies  are  all  working  towards  single  logical  data  bases,  common  platforms, 
common  software;  reducing  the  number  of  different  CAD  systems:  and  the  leveraging  of 
standards.  The  problem  with  these  efforts  is  that  they  are  aimed  at  the  needs  of  the  individ¬ 
ual  companies,  with  little  consideration  of  the  needs  of  their  hundreds  of  suppliers.  OEMs 
are  treating  each  supplier  as  an  extension  of  only  their  own  companies,  while  in  reality  most 
supplier  companies  must  do  business  with  several  OEMs  to  survive.  This  results  in  a  mul¬ 
titude  of  systems  and  related  expenses  in  the  supply  base. 

Engineering  services  suppliers  are  concerned  about  the  lack  of  standards  in  the 
computer-aided  design/computer-aided  manufacturing  (CAD/CAM)  area,  and  their  need  to 
buy  and  operate  as  many  as  15  different  CAD/CAM  systems  to  do  engineering  work  for  the 
Big  Three.  The  suppliers  noted  computer  cost  inefficiencies  as  high  as  350%  to  run  CAD 
systems  that  were  proprietary  to  one  company  and  necessary  to  get  business  from  that  com- 


pany.  The  inefficiencies  in  use  of  people  were  estimated  to  be  over  20%  because  of  training 
and  learning-curve  problems  when  switching  between  systems  and  OEM  programs. 

This  situation  is  also  affecting  small  part-suppliers.  Interviewing  a  supplier  of  trim 
parts  for  the  Big  Three  revealed  that  they  are  being  forced  to  purchase  and  have  trained  peo¬ 
ple  on  three  different  CAD  systems.  Other  part  suppliers  were  considering  getting  out  of 
the  automotive  business  because  of  poorly  timed  and  uncoordinated  cost-cutting  programs. 
The  purchasing  departments  want  reduced  costs,  but  the  engineering  and  manufacturing 
groups  need  to  participate  actively  in  meaningful  cost-saving  design  and  specification 
changes  via  better  integrated  activities. 

The  SATURN  project  at  General  Motors  may  give  some  hints  of  how  the  produc¬ 
tion  process  will  evolve  in  coming  years.  One  SATURN  practice  relevant  to  enterprise  inte¬ 
gration  is  the  “partnership”  approach  with  component  suppliers.  While  this  term  is  certainly 
not  new,  SATURN  is  attempting  to  breathe  life  into  the  rhetoric  that  often  accompanies  sup¬ 
plier  partnerships.  Suppliers  share  more  of  the  development  costs,  but  also  share  the 
rewards  and  risks.  In  a  recent  recall,  the  responsible  supplier  was  liable  for  the  costs  of  the 
recall.  Suppliers  must  clearly  see  the  rewards  of  this  approach  in  order  for  this  process  to 
take  root. 

GM  is  trying  to  transfer  SATURN  advances  to  the  rest  of  GM  by  transferring  key 
SATURN  employees  back  to  GM  and  having  them  sit  on  design  committees  as  new  prod¬ 
ucts  begin  development.  Process  engineering  for  new  products  is  being  guided  by  SAT¬ 
URN’S  experience.  Activities  such  as  these  may  enable  GM  in  particular,  and  the  auto 
industry  in  general,  to  improve  their  time-to-market  results.  Enterprise  integration,  as  prac¬ 
ticed  in  a  relatively  small  application  at  SATURN,  may  branch  out  across  the  industry. 

Other  contemporary  examples  of  applying  some  enterprise  integration  principles 
are  given  below.  Information  flow  in  these  examples  is  still  manual  as  there  were  no  inter¬ 
company  information  systems  in  place.  The  examples  illustrate  the  benefits  of  team  forma¬ 
tion,  and  of  accelerating  the  information  flow  between  the  OEM  and  its  suppliers. 

GM’s  H-car  development  used  a  four-phase  development  process: 

•  Phase  0:  Establish  budget,  business  case,  and  plan  for  engineering  and  design. 

•  Phase  1 :  Tooling  is  designed  and  working  prototypes  are  built. 

•  Phase  2:  Product  and  process  validation  culminate  in  pilot  production. 

•  Phase  4:  Normal  production. 
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Supplier  involvement  begins  early  in  Phase  0  which  is  the  most  complex  phase  of 
the  process  and  includes  many  steps  not  discussed  here.  Communication  within  the  auto¬ 
maker  and  between  automaker  and  supplier  must  begin  in  Phase  0.  The  information  com¬ 
municated  during  this  phase  is  highly  design  oriented.  In  later  phases  the  information 
communicated  is  simpler  and  includes  process  plans,  schedules,  or  JIT  flags. 

Ford  and  Chrysler  also  have  their  advanced-concept  projects  like  SATURN,  Alpha 
and  Liberty,  respectively.  However,  they  are  not  yet  marketing  or  manufacturing  a  product; 
these  projects  appear  to  be  product  and  process  teams  with  little  disclosed  about  their  spe¬ 
cific  activities. 

At  Ford,  a  program  manager  is  responsible  for  new  car  development  from  start  to 
finish.  The  development  process  generally  occurs  on  four  fronts:  quality  improvement,  cus¬ 
tomer  requirements,  competition,  and  costs.  Early  in  one  project,  as  costs  were  being  deter¬ 
mined,  the  project  team  went  to  Ford  plants  and  independent  suppliers  to  understand  the 
cost  parameters.  This  method  contrasted  with  development  programs  of  the  past  where 
costs  were  dictated  without  such  research  that  ensured  targets  could  be  met.  Hourly  workers 
were  also  part  of  the  process,  dealing  with  2,000  issues  of  tooling  through  the  process.  This 
approach  suggests  that  the  information  infrastructure  supporting  enterprise  integration  be 
designed  so  as  to  produce  information  from  both  the  customer  and  the  supplier  levels  that 
can  be  used  by  the  production  worker  as  well  as  management 

At  Chrysler,  four  platform  teams  combine  representatives  from  engineering,  pro¬ 
curement,  manufacturing,  design,  strategic  development,  sales  and  marketing,  finance,  and 
outside  suppliers.  With  these  groups,  product  development  teams  are  formed  for  specific 
vehicles  such  as  Chrysler ’s  Grand  Cherokee.  The  Cherokee  team  was  given  unusual 
authority  in  product  definition  and  design.  Changes  were  made  (with  supplier  input)  with¬ 
out  approval  from  high-level  managers;  the  only  proviso  was  that  overall  cost  and  quality 
targets  were  met.  Supplier  activity  occurred  well  before  product  approval  from  the  com¬ 
pany’s  policy  committee  had  been  obtained.  After  that  point,  senior  management  limited 
its  direct  involvement  with  the  program:  quarterly  reviews  were  held  and  prototypes  were 
driven. 

C.1.4  BUSINESS  STRATEGIES 

The  North  American  OEMs  are  all  international  companies  and,  because  of  their 
financial  problems  in  this  country,  are  relying  more  and  more  on  offshore  strategic  partners 
for  many  functions,  including  some  vehicle  production.  GM  currently  has  a  complete  line 
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of  foreign  cars  which  it  markets  under  the  GEO  nameplate.  One  of  these  cars  was  designed 
in  Germany,  and  is  produced  in  South  Korea  and  sold  in  North  America.  Ford  has  partner¬ 
ships  with  Mazda  and  Nissan  and  recently  purchased  Jaguar.  Chrysler  has  joint  ventures 
with  Mitsubitshi  and  Maserati.  Figure  C-2  summarizes  these  relationships  as  they  existed 
in  the  late  1980s. 


Figure  C-2.  Global  Network  of  Automobile  Producers  in  the  Late  1980s 

Source:  Clark  &  Fujimoto,  Product  Development  Performance,  Harvard  Business  School 
Press. 

The  University  of  Michigan  Office  for  the  Study  of  Automotive  Transportation 
(OSAT)  activity  predicts  that  Honda  and  Mazda  will  continue  to  be  assemblers  of  cars  and 
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producers  of  selected  components  in  North  America,  but  the  critical  engineering  and  prod¬ 
uct-development  work  will  continue  to  be  done  in  Japan.  However,  OSAT  also  predicts  that 
Toyota  and  Nissan  will  truly  become  world  car  companies  with  design,  engineering  and 
manufacturing  in  Japan,  North  America,  and  Europe.  The  transplants  are  currently  adding 
only  IS  to  20%  of  total  value  in  this  country.  The  product  development  and  the  engineering, 
both  product  and  manufacturing,  are  being  done  in  Japan,  and  many  of  the  components 
(particularly  the  powertrain)  are  being  shipped  in  from  other  parts  of  the  world. 

All  the  North  American  automotive  companies,  including  the  transplants,  are  devel¬ 
oping  business  strategies  aimed  at  manufacturing  simplification  and  flexibility.  These  strat¬ 
egies  include  concepts  such  as  re-engineering  business  procedures,  concurrent  engineering, 
standards  and  common  platforms,  and  taking  advantage  of  strategic  partners  from  around 
the  world. 

GM  is  working  on  a  rationalization  of  its  product  life  cycle  called  “Four  Phase.”  A 
“systems  engineering  center”  with  people  from  GM,  EDS,  and  Hughes  has  been  estab¬ 
lished  for  that  purpose.  They  are  defining  and  documenting  in  great  detail  the  task  and  tim¬ 
ing  for  each  step  needed  to  build  a  quality  car  in  minimal  time.  GM  is  also  working  with  its 
supplier  base  to  implement  a  process  called  synchronous  manufacturing.  This  process 
incorporates  features  of  TQM,  JIT,  and  CPI.  One  company,  General  Physics,  is  already 
offering  training  in  this  process.  Some  GM  divisions  have  developed  supplier  development 
programs  to  help  suppliers  understand  and  implement  new  systems  and  technology.  One  of 
the  leaders  in  this  area,  GM  Truck  and  Bus,  was  cited  by  one  of  the  companies  we  inter¬ 
viewed  as  very  easy  to  work  with.  GM  has  formed  a  “Manufacturing  Technology  Council,” 
made  up  of  high-level  managers  who  are  defining  and  implementing  strategies  for  world- 
class  manufacturing.  These  strategies  are  ail  ptut  of  enterprise  integration. 

Ford  has  a  vision  for  continuous  improvement  that  is  driven  by  cost,  quality  and 
time.  It  has  assigned  a  high-level  manager  to  each  first-tier  supplier  to  identify  and  solve 
any  problem  associated  with  cost,  time,  or  quality  of  any  part  that  the  supplier  sells  to  Ford. 
Ford  believes  in  new  technology  and  has  a  program  to  search  the  world  for  technology  it 
thinks  will  be  a  winner  and  implement  it  as  soon  as  practical.  Ford  believes  it  cannot  wait 
for  standards  for  new  technology,  which  normally  take  4  tolO  years  to  develop.  From  a 
business  point  of  view.  Ford  follows  the  development  of  standards  but  is  not  interested  in 
participating  in  their  development.  Ford,  like  GM,  has  spent  considerable  time  in  studying 
its  product  life  cycle.  Several  months  have  been  taken  out  of  their  sheet  metal  development 
time  while  improving  quality. 
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One  source  said,  “Ford  today  is  getting  their  dies  for  exterior  panels  from  five  com¬ 
panies,  four  of  which  are  offshore.  The  U.S.  company  is  currently  filing  for  Chapter  1 1 
bankruptcy.”  All  of  the  Big  Three  are  reducing  the  number  of  first-tier  suppliers  to  reduce 
their  communication  problems. 

C.1,5  INFORMATION  INFRASTRUCTURE 

Currently  the  automotive  companies  have  many  information  systems  within  the 
confines  of  the  company.  They  are  characterized  as  local,  in  that  a  system  will  serve  a 
department,  site,  or  even  an  entire  company,  but  does  not  span  companies  to  cover  an  enter¬ 
prise.  Today’s  systems  are  fairly  static.  Once  they  are  configured  for  such  things  as  data 
storage  capacity,  communications  interconnections,  and  processing  capability,  they  are  not 
easily  changed  to  meet  the  demands  of  an  ever-changing  organization.  Additionally,  the 
information  systems  are  typically  used  for  limited  functions.  For  example,  CAD  systems 
for  design  are  completely  isolated  from  accounting  information  systems  or  automated 
scheduling  systems.  Any  type  of  cross-system  processing  must  be  done  manually. 

There  are  very  few,  if  any,  provisions  for  cross-organization  automated  information 
flow.  If  there  is  to  be  any  flow  of  this  nature,  both  organizations  must  have  similar  systems, 
or  the  data  representing  the  information  cannot  be  interpreted.  For  example,  all  three  U.S. 
automotive  companies  have  their  preferred  CAD  package,  and  each  sees  its  choice  as  a 
competitive  advantage.  Chrysler  uses  Catia,  Ford  has  a  Prime-based  system,  and  GM  has 
the  Corporate  Graphics  System  (CGS).  They  all  force  the  use  of  their  system  on  suppliers 
of  major  sheet  metal  exterior  panels.  Engineering  service  firms  supplying  all  three  with 
design  services  must  purchase,  be  trained  on,  and  maintain  each  of  the  proprietary  systems 
required  by  the  client.  The  cost  of  maintaining  a  proprietary  system  is  enormous.  For  the 
automotive  OEM,  this  cost  can  reach  $10  million  per  year,  using  a  staff  of  around  100  peo¬ 
ple.  The  service  and  supplier  organizations,  while  maintaining  much  smaller  versions,  must 
also  bear  large  costs  of  maintenance  for  multiple  proprietary  systems. 

GM  over  the  years  has  been  a  decentralized  company  with  as  many  as  25  divisions 
competing  with  one  another  for  some  part  of  their  business.  This  competition  has  lead  to 
many  different  sets  of  business  and  engineering  systems  and  procedures.  Under  the  direc¬ 
tion  of  David  Hill,  Executive  in  Charge  of  Information  Systems,  GM  is  in  the  process  of 
rationalizing  and  integrating  all  of  their  systems.  GM  constructed  a  corporate  vision  for 
integration  in  which  all  of  the  major  groups  participated.  They  are  working  on  common  sys¬ 
tems  in  all  of  their  functional  areas:  marketing,  engineering,  manufacturing,  accounting. 
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materials,  and  office  management.  Their  C-4  project  is  working  toward  the  rationalization 
of  their  engineering  community.  They  are  also  working  on  common  data  elements  and  a 
dictionary.  In  this  program,  they  will  be  reducing  the  number  of  CAD  systems  in  GM  fi-om 
12  to  4,  including  CGS,  CADAM,  and  Unigraphics.  In  this  total  process,  they  are  develop¬ 
ing  a  variety  of  data,  information,  and  reference  models  using  various  modeling  techniques. 
These  systems  will  be  based  on  existing  national  and  international  standards.  GM  has  been 
a  very  active  player  in  the  standards  development  community. 

In  Ford,  according  to  S.l.  Gilman,  because  of  centralized  control  and  minimal  inter¬ 
nal  competition,  problems  of  integration  have  not  been  as  severe.  Today  Ford  has  two  CAD 
systems,  one  for  exterior  panels  and  one  for  component  parts.  Ford  has  a  single  engineering 
release  system  and  reasonable  standards  in  its  manufacturing,  dealer,  and  office  systems. 
Ford  is  working  toward  common  platforms  and  common  software  in  most  parts  of  its  busi¬ 
ness,  but  not  across  the  total  corporation.  For  example,  powertrain  plants  have  one  common 
platform  and  set  of  standards,  while  components  plants  may  have  another  platform  and  set 
of  standards.  Their  standards  for  the  most  part  £q>pear  to  be  Ford  standards,  rather  than 
national  or  international.  However,  Ford  does  clearly  see  the  need  for  international  stan¬ 
dards  and  appears  to  be  willing  to  use  them  when  appropriate.  Ford  complained  dtat  stan¬ 
dards  take  too  long  to  develop  and  voiced  an  unwillingness  to  participate  in  their 
development  Even  though  it  is  working  toward  common  platforms  and  standards,  it  is  not 
clear  that  Ford  has  a  vision  for  total  integration. 

C.1,5.1  Electronic  Data  IVansfer 

One  result  of  the  weakness  of  existing  data  exchange  standards  in  the  auto  industry 
is  the  recent  rise  of  companies  offering  services  in  support  of  electronic  data  interchange 
(EDI).  Automotive  supplier  companies  can,  for  a  price,  take  product  data  that  has  come 
from  their  customers  to  one  of  these  services  to  be  translated  into  a  form  that  they  can  use 
on  their  own  systems.  Services  can  provide  two  basic  kinds  of  transformation:  medium-to- 
medium  transfer  (e.g.,  nine-track  tape  to  floppy  disk)  and  data-file  translation  (e.g.,  Inter¬ 
graph  to  AutoCAD).  If  a  particular  transformation  is  not  a  common  one  for  the  supplier, 
then  using  a  service  makes  sense.  However,  such  services  are  costly  and  add  to  the  time  it 
takes  to  produce  a  product  They  are  also  outside  the  control  of  the  supplier,  leading  to 
errors  and  delays,  and  thus  problems  with  die  customer.  Data  transformations  with  which  a 
supplier  must  deal  frequendy  are  best  handled  by  bringing  the  capability  in  house.  Unfor¬ 
tunately,  many  suppliers  do  not  have  the  technical  capability  to  handle  such  problems.  They 
may  be  afraid  to  undertake  the  transformations  themselves.  Worse,  they  may  purchase  inap- 


propriate  tools  with  which  they  try  (and  fail)  to  do  the  transformations,  wasting  further 
money  and  time.  Electronic  data  transfer  services  can  perform  a  useful  task  here,  but  if  data 
exchange  standards  were  well  defined  and  widely  adopted,  such  services  would  be  much 
less  necessary. 

C.1.6  LESSONS  LEARNED 

The  GM  SATURN  Corporation  was  conceived  with  integration  of  people,  technol¬ 
ogy,  and  information  in  its  mission  statement.  In  visiting  a  SATURN  plant,  we  noticed  a 
strong  relationship  between  information,  people,  and  activity  on  the  production  floor.  This 
integration  appears  to  have  contributed  to  a  very  efficient  operation  with  extremely  low 
inventory,  high  quality,  and  a  highly  motivated  workforce. 

SATURN  learned  a  number  of  lessons  during  the  implementation  of  integrated 
information  systems: 

•  Standards  are  essential. 

•  Strategic  partners  (suppliers  of  parts,  services  or  technologies)  are  important 

•  Data  ownership  implies  the  responsibility  of  data  administration. 

•  Change  management  for  information  systems  requires  a  high  degree  of  coordi¬ 
nation. 

•  SATURN  feels  that  MAP  (Manufacturing  Automation  Protocol)  is  the  right 
direction  for  manufacturing  communications. 

•  People  in  all  levels  of  the  workforce  must  play  a  role  in  defining  the  information 
needs  to  run  the  business. 

•  A  single  CAD  system  is  essential. 

•  Common  applications  can  be  used  across  most  of  manufacturing. 

In  visiting  other  automotive  OEMs,  first-tier  suppliers,  and  OSAT,  we  reached  addi¬ 
tional  conclusions  about  integration: 

•  Most  large  companies  have  information  standards  and  are  working  toward  some 
level  of  information  integration  within  their  own  company,  with  little  consider¬ 
ation  for  their  suppliers. 

•  Companies  can  integrate  their  own  internal  operations,  but  suppliers  who  work 
for  multiple  OEMs  need  help  in  the  form  of  enablers. 
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•  Automotive  OEMs  have  business  interests  in  proprietary  CAD  systems,  which 
they  force  on  suppliers  of  engineering  services. 

•  Integration  can  reduce  the  lead  TTM  and  engineering  by  30%  and  reduce  cost 
by  20%. 

•  Most  of  the  automotive  OEMs  are  international  companies  and  want  interna¬ 
tional  standards. 

•  Some  large  companies  will  follow  standards  if  they  exist  but  do  not  want  to  par¬ 
ticipate  in  their  development. 

•  The  Automotive  Industry  Action  Group  (ALAG)  is  moving  in  the  right  direction 
of  automotive  standards,  but  they  need  help  in  moving  faster. 

C.1.7  COOPERATIVE  EFFORTS 

C.1.7.1  The  AIAG 

The  AIAG  is  a  cooperative  effort  that  was  widely  cited  by  our  interviewers  and  pan¬ 
elists.  It  is  an  organization,  that  was  formed  in  the  early  1980s  by  a  group  of  materials  engi¬ 
neers  who  saw  that  a  new  kind  of  cooperative  effort  by  North  American  vehicle 
manufacturers  could  improve  productivity,  strengthen  quality,  and  reduce  non-value-added 
costs  throughout  the  industry.  It  now  has  over  700  corporate  members.  AIAG  is  operated 
by  a  team  of  6  full-time  executives  on  loan  from  member  companies,  supported  by  an 
administrative  staff  and  a  21-member  Board  of  Directors. 

The  real  work  of  AIAG  is  accomplished  by  nine  project  teams  and  their  associated 
work  groups.  These  teams  and  groups  are  made  up  of  some  900  volunteers  from  the  mem¬ 
ber  companies.  AIAG  has  two  types  of  project  teams.  One  focuses  on  technology  and  the 
other  deals  with  business  functions.  The  technology  project  teams  are  EDI,  CAD/CAM, 
Returnable  Containers,  and  Automatic  Identification  (Bar  Coding).  The  business  project 
teams  are  Continuous  Quality  Improvement,  Finance,  Materials  Management,  Transporta¬ 
tion,  and  Purchasing. 

The  project  teams  develop  standards,  guidelines,  and  conventions  that  apply  to 
technological  and  business  function  areas.  All  EDI  standards  are  approved  at  the  American 
National  Standards  Institute  (ANSI)  X.12  level.  AIAG  also  cooperates  with  various  stan¬ 
dards  organizations  such  as  ANSI,  the  Initial  Graphics  Exchange  Specification/Product 
Description  Exchange  Standard  (IGES/PDES)  Organization  (IPO),  and  the  Organization 
for  Data  Exchange  by  Tele  Transmission  in  Europe  (ODETTE). 
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Many  in  the  auto  industry  look  to  AlAG  as  an  important  resource  for  making  the 
industry  more  competitive  internationally.  However,  the  general  feeling  is  that  AIAG  is  not 
living  up  to  its  potential.  Activities  are  seen  as  too  limited  in  scope  and  too  slow  in  accom¬ 
plishing  their  goals.  Furthermore,  there  are  real  questions  among  those  who  take  part  in 
AIAG  work  groups  that  the  industry  will  appreciate  and  accept  their  work. 

For  example,  the  CAD/CAM  Project  Team’s  Data  Exchange  Work  Group  is  trying 
to  improve  the  movement  of  CAD  data  down  the  supplier  chain.  This  is  not  easy,  as  there 
are  numerous  CAD  and  CAM  systems  being  used  by  automotive  suppliers.  Theoretically, 
IGES  should  suppon  the  movement  of  such  data  between  dissimilar  systems.  Unfortunate¬ 
ly,  there  are  many  problems  between  IGES  itself  and  the  systems  that  use  it.  The  result  is 
difficulty  in  the  movement  of  data.  A  major  concern  among  those  who  participate  in  the 
Data  Exchange  Work  Group  is  that  they  will  come  up  with  tools  and  methods  to  improve 
IGES  data  exchanges,  but  the  big  automotive  manufacturers  will  not  use  them.  Indeed,  it  is 
the  stated  policy  of  some  of  the  automakers  that  their  suppliers  must  use  their  proprietary 
or  captive  CAD  systems.  This  policy  is  adhered  to  in  spite  of  the  inability  of  small  suppliers 
to  support  one  such  expensive  CAD  system,  much  less  two  or  three.  In  other  words,  AIAG 
has  a  problem  getting  buy-in  from  its  own  members,  not  to  mention  the  auto  industry  as  a 
whole.  This  concern  applies  across  most  of  AlAG’s  work  groups. 

A  further  problem  is  that,  the  900  volunteers  listed  by  AIAG  as  working  on  the  work 
groups  are  too  few  to  accomplish  major  efforts.  There  are  about  40  work  groups  and  there¬ 
fore  roughly  20  volunteers  per  group.  At  any  one  meeting  many  will  be  absent,  and  the 
AIAG  work  comes  after  their  regular  responsibilities,  so  the  actual  number  of  people  avail¬ 
able  to  do  work  per  group  is  quite  small.  A  slow  progress  with  limited  results  should  be  no 
surprise. 

For  AIAG  to  fulfill  its  potential,  it  needs  to  have  real  buy-in  by  all  its  member  cor¬ 
porations,  manifested  by  the  broad  adoption  and  use  of  the  standards  promulgated  by  AIAG 
work  groups  and  the  dedication  of  more  people  and  time  to  the  effort.  Until  that  happens, 
AIAG  will  continue  to  be  disappointing  in  its  overall  effect  on  the  auto  industry. 

C.1.7.2  CAM-I 

CAM-I  is  a  broad  consortium  of  companies,  the  U.S.  Navy,  and  the  U.S.  Air  Force 
that  forms  teams  and  expertise  to  solve  common  manufacturing  industry  problems.  The 
consortium  provides  applied  research  plans  for  developing  and  testing  new  concepts.  Its 
initiatives  focus  on  process  planning,  quality  assurance,  advanced  numerical  control,  prod- 
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uct  modeling,  and  manufacturing  management  programs.  CAM-I  has  conducted  case  stud¬ 
ies  of  exemplary  programs  under  its  CIE  (Computer  Integrated  Enterprise)  program,  and 
has  generally  underscored  the  importance  of  issues  of  organizational  culture  in  approaching 
world-class  manufacturing.  Because  CAM-1  is  convinced  that  the  issues  facing  the  small 
supplier  are  of  paramount  importance,  the  consortium  is  establishing  a  new  group  to  focus 
on  supplier  development.  The  interest  in  the  suppliers’  relationship  to  enterprise  integration 
is  strong. 

C.1.7.3  NCMS 

The  National  Center  for  Manufacturing  Sciences  (NCMS)  in  Ann  Arbor,  Michigan, 
has  two  groups  working  on  Integration  for  the  Automotive  Industry.  One  group  is  working 
on  a  reference  model  and  the  management  issues  that  are  a  barrier  to  integration.  This  group 
has  strong  membership  from  Ford  and  GM  as  well  as  non-automotive  companies. 

C.2  AUTOMOTIVE  INDUSTRY:  2001 
C.2.1  THE  VISION 

The  vision  described  here  is  based  principally  upon  two  workshops  involving  a  pan¬ 
el  of  auto  industry  experts.  The  two  days  of  roundtable  panel  discussions  were  supplement¬ 
ed  with  written  documents  describing  and  projecting  automotive  concepts  and  activities  in 
the  United  States^  and  Japan.^  The  roundtable  panel  first  established  a  vision  that  took  into 
account  key  dimensions  of  the  automotive  product,  manufacturing  processes,  people,  sup¬ 
pliers,  facilities,  dealers,  and  information  systems.  Initial  discussions  of  elements  of  the 
vision  were  reviewed  and  integrated  by  the  project  team  for  the  second  workshop,  involv¬ 
ing  the  same  panel,  which  occurred  about  two  weeks  later.  At  that  time,  the  panel  developed 
a  vision  reflecting  four  essential  aspects  of  the  automotive  process: 

(1)  The  product 

(2)  Concept  design  and  marketing  of  the  product 

(3)  Concurrent  detailed  product  and  process  design 

^  Ernst  &  Young.  The  Car  Company  of  the  Future:  A  Study  of  People  and  Change.  A  Joint  Research  Project 
of  Ernst  &  Young  and  the  University  of  Michigan,  1991  (SCORE  Retrieval  File  No.  700002). 
Association  for  Manufacturing  Excellence.  Manufacturing  21  Report:  The  Future  of  Japanese  Manufac¬ 
turing.  Sponsored  by  Japan  Machinery  Federation,  System  Institute  of  Waseda  University.  Translated  from 
Articles  in  Communications  of  the  Operations  Research  Society  of  Japan,  written  by  M.  Iwata,  A.  Makash- 
ima,  A.  Tateishi,  J.  Nakane,  S.  Kurosu,  &  T.  Takahashi.  Wheeling,  IL:  AME  (380  West  Palatine  Road, 
60090). 
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(4)  Operations  and  service 

From  those  four  elements  of  the  vision,  implications  were  drawn  for  the  information 
structure  that  would  support  that  vision.  'Fhose  information  infrastructure  implications  are 
discussed  in  a  subsequent  section. 

C.2.1.1  Product 

Definition  of  the  product  is  the  first  essential  aspect  of  the  automotive  business 
rationale.  In  general,  there  will  be  more  automobile  models,  and  those  models  will  have 
shorter  production  lives.  The  life  cycle  of  all  the  models,  from  concept  to  end-of-produc- 
tion,  will  be  much  shorter.  Production  time  will  be  shorter,  and  cars  will  last  longer.  The 
products  will  be  characterized  by  high  quality  and  environmental  and  social  acceptability. 

A  key  feature  of  the  automotive  product  of  2001  will  be  customization  for  niche 
markets.  Quality  and  cost  will  approach  uniformity  and  will  give  way  to  customization, 
flexibility,  and  programmability  of  features  as  the  drivers  of  competitive  advantage.  Small- 
er-volume  niche  cars  are  becoming  an  important  portion  of  the  automobile  market.  Current 
examples  are  import  luxury  cars,  custom  vans,  and  low-volume  sports  cars.  In  general,  this 
low- volume,  niche-car  set  of  markets  will  continue  to  evolve  and  grow  through  the  1990s. 
That  trend  is  supported  by  the  growing  number  of  multi-car  families,  where  the  second  car 
is  a  “niche”  car.  The  family  typically  has  one  vehicle  for  transporting  the  family,  while  indi¬ 
vidual  family  members  may  have  high-performance,  luxury,  or  other  specialty  vehicles  for 
daily  or  recreational  use. 

The  move  toward  models  with  shorter  life  cycles  will  occur  in  the  context  of  bound¬ 
ed  customization,  dictated  by  the  demographics  and  needs  of  the  customer  marketplace. 
Currently,  customers  are  adopting  longer  lifetimes  for  vehicle  use,  based  principally  on 
price  and  financing.  As  national  demographics  change,  the  definition  of  the  customer  base 
and  niche-buyers  will  also  change.  Lower-volume  production  niches  will  also  be  accom¬ 
modated  by  different  customer-use  patterns,  especially  the  increasing  trend  toward  leasing 
and  fleets  for  business  use. 

The  ability  to  provide  unique  features  in  cars  will  supplement  this  emphasis  on  cus¬ 
tomization.  Customizable  features  will  go  beyond  today’s  capabilities  for  and  provision  of 
option  selection.  Customizable  features  could  range  from  exterior  and  interior  finishes  to 
custom  body  skins.  Buyers  could  thus  put  their  personal  “mark”  on  their  vehicle  and,  to  a 
certain  extent,  contribute  to  the  design  of  the  car  to  suit  their  own  needs  or  interests. 
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Uniqueness  could  also  be  captured  in  programmable  features  including  seats,  dash  controls 
and  instrumentation,  and  convenience  features  of  the  car. 

The  feasibility  of  including  custom  features  in  the  vehicles  will  be  supported  by 
new  materials  and  production  processes.  More  vehicles  will  have  plastic  skins,  and 
advanced  composites,  while  not  in  high-volume  production  in  200 1 ,  will  be  moving  rapidly 
upward  on  the  development  curve.  Newer  composite  materials  will  start  coming  into  use. 
Different  lines  of  vehicles  will  share  common  subsystems.  Incorporating  these  subsystems 
and  meeting  goals  of  more  models  with  shorter  life  cycles  will  involve  assembling  larger 
components  into  the  final  automobile.  The  components  will  be  in  the  form  of  assemblies 
and  subsystems  received  from  first-tier  suppliers  at  centralized  assembly  plants. 

The  potential  for  programmable  customization  implies  that  automobiles  will  have 
increasing  software  content.  Software  is  already  evident  in  a  number  of  features,  including 
audio  systems  and  computer-controlled  braking  systems.  Currently  the  bulk  of  the  software 
is  contained  in  dedicated,  embedded  systems  over  which  the  driver  and  passenger  have  no 
control.  In  the  future,  programmable  features  will  allow  some  user  control.  Some  possibil¬ 
ities  for  programmable  features  include  reconfigurable  instrument  clusters  that  allow  the 
user  to  program  a  display  by  the  position,  size,  and  contrast  of  indicators;  programmable 
seating  systems  positioning:  more  programmable  suspension  systems;  and  variable  steering 
and  transmissions.  Drivers  would  be  able  to  configure  the  operational  features  of  the  car  to 
fit  preferences  for  driveability. 

Economic  and  environmental  concerns  will  drive  requirements  that  the  automobile 
of  2001  be  recyclable  and  reusable.  TTiis  trend  is  already  beginning  to  occur  in  Europe, 
where  Germany  is  in  the  process  of  ratifying  recycling  laws  for  automobiles  sold  in  that 
country.  The  automotive  manufacturer  will  be  responsible  for  the  recycling  process.  To 
achieve  that,  the  customer  will  essentially  be  a  user  of  the  vehicle  that  the  automotive  com¬ 
pany  will  “own.”  At  the  end  of  the  product’s  useful  life,  the  manufacturer  will  get  it  back 
for  disposal  and  recycling  of  parts.  If  predictions  of  increases  in  society’s  division  of  wealth 
prove  correct,  the  widening  gap  between  the  “haves”  and  “have  nots”  in  society^  will  create 
a  larger  market  for  used  vehicles.  There  will  be  reusable  parts  and  subsystems  within  cars 
that  have,  on  the  whole,  reached  the  end  of  their  useful  product  lives.  Usable  subsystems 
could  then  be  upgraded  for  incorporation  in  reconditioned  cars  that  could  become  part  of 
the  used-car  market 

^  Ernst  &  Young.  The  Car  Company  of  the  Future:  A  Study  of  People  and  Change.  A  Joint  Research  Project 
of  Ernst  &  Young  and  the  University  of  Michigan,  1991  (SCORE  Retrieval  File  No.  T(X)002). 
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C.2.1.2  Conceptual  Design  and  Marketing 

Customization  and  niche  cars  will  dictate  the  need  for  more  intense  :..id  individual¬ 
ized  market  testing  and  conceptual  design.  To  meet  the  variable  definition  of  desired  prod¬ 
ucts,  there  will  need  to  be  faster  customized  product  definition.  Model  development,  to  be 
competitive,  simply  has  to  be  faster  and  cheaper.^  A  current  typical  model  life  runs  around 
10  years.  In  all  likelihood,  this  life  span  will  shorten  considerably  for  companies  to  remain 
competitive.  Demographic  market  studies  can  be  reduced  from  a  current  three-  to  five-year 
perspective  to  one  to  three  years.  Niches  of  need  and  preference  can  be  identified  in  that 
time  frame  for  main  vehicle  areas  of  performance,  powertrain,  or  styling.  Products  can  be 
better  defined  for  entry  level  and  midscale  vehicles.  This  concept  design  and  marketing 
phase  will  also  assist  in  the  early  identification  of  customizable  features  for  design  and 
common  parts  families  for  manufacture. 

Concepts  can  be  tested  with  the  technology  of  “virtual  reality.”  Virtual  reality,  in 
which  the  user  gets  direct  control  of  and  sensory  feedback  from  manipulations  of  the  envi¬ 
sioned  product,  will  replace  the  use  of  sketches  and  costly  market  clinics.  Concept  testing 
will  involve  virtual  cars  with  instantaneous  capabilities  and  information  for  interchange- 
ability,  redesign  and  cost.  With  CAD  and  graphics  packages,  one  can  show  potential  cars 
and  simulate  test  drives  for  the  prosumer  (formerly  conceived  as  the  “consumer”)  at  the 
dealership.  Dealers  will  be  more  involved  in  the  enterprise  partnership  by  havmg  inputs  to 
design. 

Simulations  will  be  more  extensively  used  for  prototyping.  Clay  models  may  still 
be  used  to  confirm  mathematically  derived  surfaces  and  overall  visual  perspectives.  But 
simulations  via  computer  can  replace  hand-built  functional  prototypes  for  testing  buildabil- 
ity  and  assembly  processes.  The  computer  will  play  a  greater  role  in  prototyping,  with  less 
of  a  need  for  physically  tangible  prototypes.  Simulations,  testing,  and  go/no-go  decisions 
will  rest  less  on  senior  management  and  more  so  the  design/build  team.  Physical  protoypes 
will  be  used  where  necessary  for  such  activities  as  crash-testing  and  fuel-efficiency  assess¬ 
ments. 


^  Association  for  Manufacturing  Excellence.  Mamtfacturing  21  Report:  The  Future  of  Japanese  Manufac¬ 
turing.  Sponsored  by  Japan  Machinery  Federation,  System  Institute  of  Waseda  University.  Translated  from 
Articles  in  Communications  of  the  Operations  Research  Society  of  Japan,  written  by  M.  Iwata,  A.  Makash- 
ima,  A.  Tateishi,  J.  Nakane,  S.  Kurosu,  &  T.  Takahashi.  Wheeling,  EL;  AME  (380  West  Palatine  Road, 
60090). 
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Designs  will  become  more  modular.  Since  not  every  subsystem  need  go  through 
redesign  for  new  models,  a  more  modular  design  and  product  will  facilitate  product  cus¬ 
tomization  and  more  rapid  model  introduction.  Modularity  will  also  increase  the  common¬ 
ality  of  subsystems  and  subassemblies  across  models  for  those  systems  that  are  not  viewed 
as  unique  to  a  model.  Current  examples  include  window  mechanisms  and  exhaust  systems. 
Modularity  can  also  be  extended  to  drivetrains  and  electronics  systems  within  the  automo¬ 
bile. 


C.2.1.3  Concurrent  Detailed  Product  and  Process  Design 

The  design  of  the  product  and  processes  for  manufacturing  will  become  even  more 
simultaneous  activities.^  Concurrent  engineering  and  design  can  be  structurally  facilitated 
by  design  teams  of  people  from  multiple  functions  and  by  design  centers  of  physically  co¬ 
located  team  members.  Design  teams  will  involve  higher  degrees  of  business  functional 
integration,  not  just  among  product  and  process  design,  but  extending  to  sales,  production, 
and  materials.  There  may  be  many  concurrent  design  teams  (for  different  models,  or  as  tiger 
teams  in  the  design  process)  operating  within  a  firm  or  location.  The  emphasis  is  on  func¬ 
tionally  broadened,  not  numerically  larger,  design  teams.  The  information  systems  can  be 
appropriately  distributed,  but  the  design  team  concept  must  preserve  scalability  by  bound¬ 
ing  the  cost  to  accomplish  the  process.  The  design  teams  will  be  composed  of  many  auton¬ 
omous  but  interacting  elements,^  which  will  require  extensive  information  exchange. 
Design  teams  will  be  able  to  be  informed  instantly  of  changes  in  designs  and  requirements, 
through  an  enhanced  information  infrastructure. 

The  acceleration  of  joint  product/proccss  design  is  also  likely  to  permit  greater 
attention  to  both  the  front  and  back  ends  of  the  manufacturing  life  cycle  including  design 
for  “disassembly”  as  well  as  the  traditional  emphasis  on  design  for  assembly  and  manufac¬ 
ture,  The  emphasis  on  design  of  the  end  of  the  process  will  facilitate  the  product  objective 
of  recyclability  and  reusability  discussed  earlier. 

Information  from  concept  and  design  development  efforts  will  be  captured  and 
saved,  even  if  potential  auto  programs  are  cancelled  in  midstream.  Rejected  concepts  will 


^  Association  for  Manufacturing  Excellence.  Manufacturing  21  Report:  The  Future  of  Japanese  Manufac¬ 
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Articles  in  Communications  of  the  Operations  Research  Society  of  Japan,  written  by  M.  Iwata,  A.  Makash- 
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be  stored  for  possible  resurrection  and  modification  for  other  applications.  This  capability 
will  require  increased  storage  and  access  capabilities  and  mechanisms  that  allow  designers 
to  capture  design  intent.  Firms  will  capture  lessons  learned  in  order  to  reduce  future  mis¬ 
takes. 

In  addition  to  enhancing  the  product  design,  the  concurrent  design  process  will  also 
improve  manufacturing  tools  and  systems.  CAD/CAM  systems  will  quickly  produce  dies 
and  tooling  from  product  designs  and  process  plans.  Die  manufacture  will  include  only 
“critical  tolerancing.”  Critical  tolerances  will  not  be  required  for  aspects  of  the  die  that  do 
not  make  a  difference  in  fit  or  usage.  Equipment  will  be  better  and  more  easily  retooled  or 
reprogrammed  for  building  new  products. 

C.2.1.4  Operations  and  Service 

The  rapid  introduction  of  concurrently  designed,  customized  products  utilizing  new 
materials  and  larger  subassemblies  has  direct  implications  for  the  vision  of  production 
operations  and  service  follow-up  in  2001. 

By  designing  the  product  and  the  process  in  parallel,  manufacturers  can  realize 
coordinated  process  planning  when  interfaces  develop  among  different  process  plans.  Pro¬ 
cess  planning  will  be  linked  among  OEMs,  suppliers,  and  equipment  vendors.  There  will 
be  coordinated  but  autonomous  design  for  existing  processes  and  equipment  to  build  dif¬ 
ferent  vehicles,  helping  to  link  elements  in  enterprise  partnership.  Supplier  partners  will 
possess  broader  technical  OEMs  capabilities  and  have  better  managed  relationships  with 
their  major-manufacturer  customers.  This  phenomenon  will  lead  to  an  industry  structure  of 
greater  distributed  manufacturing,  involving  a  host  of  smaller,  more  “manufacturing- 
expert”  companies.  The  vision  of  distributed  manufacturing  operations  could  involve  a 
“virtual  corporation,”  or  an  enterprise,  of  more  than  250  suppliers. 

The  introduction  of  new  advanced  materials  and  subassemblies  previously 
described  will  have  implications  for  operations,  in  that  many  basic  manufacturing  opera¬ 
tions  will  change.  New  materials  will  reduce  the  requirements  for  metal  stamping  capacity 
and  impose  needs  for  new  kinds  of  forming  and  processing.  Drivetrain  components  are 
likely  to  be  manufactured  using  “near  net  shape”  processes.  Precision  building  of  the  vehi¬ 
cle  chassis  will  be  required  to  facilitate  automated  manufacturing  activities.  Overall  man¬ 
ufacturing  systems  will  have  to  be  more  flexible  to  accommodate  rapidly  changing  product 
models  and  shorter  life  cycles.  Assembling  vehicles  will  consist  of  putting  together  fewer. 
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larger  subassemblies,  as  opposed  to  piece- by-piece  assembly.  Assembly  plants  will  have  to 
handle  “batches  of  one,”  as  more  niche  cars  and  custom  vehicles  become  reality. 

The  timing  and  technologies  for  production  scheduling  will  change  in  the  vision  of 
2001.  Much  of  the  scheduling  activity  will  be  driven  by  the  desire  for  the  “rapid  delivery” 
car,^  in  which  the  time  from  order  to  delivery  of  a  new  car  is  matter  of  days.  The  notion  of 
rapid  delivery  pervades  other  functional  components  of  design  as  well  as  production.  Cur¬ 
rently,  it  takes  less  than  two  days  to  assemble  a  vehicle;  the  majority  of  the  turnaround  time 
involves  the  time  required  to  process  and  queue  up  the  order  for  assembly  and  delivery. 
Scheduling  in  the  future  might  be  initiated  at  the  dealership  or  other  central  ordering  site. 
Build  schedules  will  be  tied  to  order  assignment  from  the  dealers  and  engineering  changes 
in  process.  As  a  by-product  of  being  able  to  assemble  subsystems  instead  of  smaller  com¬ 
ponents  of  the  product,  a  model  can  be  assembled  in  many  locations,  and  many  models  can 
be  assembled  at  a  single  location.  Since  it  will  be  possible  to  assemble  a  given  model  at  any 
number  of  plants,  the  scheduling  will  also  have  to  accommodate  leveling  of  plant  sched¬ 
ules,  requiring  an  information  infrastructure  component  of  electronic  schedule  information 
exchange.  This  scheduling  process  also  implies  that  principles  of  JIT  delivery  will  become 
even  more  deeply  ingrained  than  they  are  now,  and  directed  to  the  link  between  assembler 
and  customer,  as  well  as  that  between  supplier  and  assembler.  That  situation,  coupled  with 
the  notion  of  batches-of-one,  indicates  that  first-tier  and  sub-tier  suppliers  will  be  closely 
tied  into  the  scheduling  system. 

Many  functions  of  scheduling  vehicle  build  will  have  to  be  performed  in  parallel  to 
facilitate  rapid  introduction  of  niche  vehicles.  Along  with  streamlined  scheduling  and  the 
inclusion  of  more  information  content  in  schedules,  our  scenario  includes  tighter  lot  track¬ 
ing  for  purposes  of  JIT,  greater  quality  control,  and  increased  traceability  of  the  vehicle 
through  the  life  cycle.  Material  lots  required  for  the  build  will  be  tied  to  the  build  schedule. 

The  operational  vision  calls  for  new  methods  of  quality  control  of  the  manufa^'tur- 
ing  process.  Techniques  of  Statistical  Process  Control  (SPC)  and  Statistical  Quality  Control 
(SQC)  will  be  replaced  by  analyzing  more  process  and  quality  data  on  a  closed  loop,  real¬ 
time  basis  to  achieve  timely  control  and  to  maintain  high  quality  requirements.  Quality 
experiments  will  be  prescriptively  designed  to  bring  about  process  change.  Centralized 

^  Association  for  Manufacturing  Excellence.  Manufacturing  21  Report:  The  Future  of  Japanese  Manufac¬ 
turing,  sponsored  by  Jtqian  Machinery  Federation,  System  Institute  of  Waseda  University.  Translated  from 
Articles  in  Communications  of  the  Operations  Research  Society  of  Japan,  written  by  M.  Iwata,  A.  Makash- 
ima,  A.  Tateishi,  J.  Nakane,  S.  Kurosu,  &  T.  Takahashi.  Wheeling,  IL:  AME  (380  West  Palatine  Road 
60090). 


# 


control  and  maintenance  will  be  crucial  to  this  aspect  of  the  production  scenario.  The  vehi¬ 
cle  assembly  line  will  start  to  resemble  continuous  process  production  in  that  isolated 
breakdowns  will  halt  the  entire  process.  Repair  crews  will  have  to  be  dispatched  immedi¬ 
ately.  Control  rcoms  will  become  more  prevalent.  Control  rooms  have  been  used  for  several 
decades  to  monitor  overall  plant  operations,  anticipate  problems,  and  address  failures 
quickly  in  the  process  and  electrical  power  industries.  Control  rooms  are  beginning  to  take 
greater  hold,  for  the  same  purposes,  in  the  auto  industry.  To  support  rapid  dispatch  and 
problem  resolution,  the  information  system  may  include  portable  maintenance  information. 

In  addition  to  being  more  portable,  production  and  maintenance  systems  will 
become  increasingly  complex,  diversified,  and  flexible.  That  vision  will  impose  require¬ 
ments  on  the  compatibility  of  information  systems  and  human  resources.  People  will  be 
working  on  a  wide  variety  of  product  and  process  equipment.  Knowledge-based  production 
and  maintenance  will  be  required  for  rapid  solution,  or  avoidance,  of  production  problems. 

Aftermarket  service  will  also  involve  the  expanded  role  of  the  dealership  and  the 
customer  in  the  auto  enterprise.  In  addition  to  driving  some  aspects  of  design,  the  service 
centers  (integrated  within  or  separated  from  sales  outlet  “dealerships”)  will  continue  to 
increase  their  focus  on  service  and  reliability.  They  will  also  be  more  effective  at  dealing 
with  the  problem  of  having  replacement  parts  on  hand  when  needed.  Dealerships  might 
become  integrated  with  the  array  of  design,  ordering,  final  assembly,  and  delivery  functions 
in  co-located  auto  malls. 

Societal  demands  and  manufacturing  economy  considerations  will  require  the  auto¬ 
mobile  of  2001  to  be  completely  traceable  in  terms  of  the  ownership,  operation,  and  service 
of  the  vehicle  and  its  subsystems.  Traceability  is  required  to  meet  the  previously  suggested 
needs  for  environmental  protection  and  product  recycling.  Tracking  service  and  perfor¬ 
mance  and  maintaining  records  of  upgrades  will  provide  means  of  accountability  for  dis¬ 
posing  of  the  vehicle.  That  practice  will  also  provide  indications  of  required  upgrading  of 
subsystems  prior  to  reuse.  Traceability  may  be  accomplished  as  a  progranunable  feature 
within  the  automobile.  Records  can  be  kept  and  retrieved  at  times  of  service,  either  locally 
or  remotely,  for  use  by  the  auto  manufacturer. 

Some  of  the  requirements  for  an  information  infrastructure  to  support  this  vision  for 
2(X)1  are  implicit  in  the  descriptions  of  product,  design,  and  operations.  Those  implications 
are  drawn  out  in  more  detail,  in  the  context  of  key  elements  of  an  information  infrastruc¬ 
ture,  in  the  next  section  of  this  chapter.  The  vision  also  suggests  that  there  will  be  some  non- 
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technological  barriers  to  achieving  the  vision.  Those  issues  and  barriers  are  summarized  in 
Section  C.3. 

C.22  INFORMATION  INFRASTRUCTURE  IMPLICATIONS 

An  architecture  can  be  viewed  as  a  two-dimensional  function.  One  dimension  con¬ 
sists  of  the  parameters  of  principles,  inventory,  models,  and  standards.  The  other  dimension 
consists  of  the  elements  of  infrastructure  (hardware,  system  software,  and  communica¬ 
tions),  data,  applications,  and  organization.  The  architecture  begins  with  the  development 
of  overall  and  specific  principles  derived  from  the  enterprise  business  rationale.  These  prin¬ 
ciples  span  infrastructure,  data,  applications,  and  organization.  Only  then  can  the  other  ele¬ 
ments  of  inventory,  models,  and  standards  be  defined  and  developed  in  detail. 

The  information  infrastructure  is  a  component  of  the  enterprise  information  archi¬ 
tecture,  predominantly  covering  architectural  infrastructure  and  data.  This  study  synthe¬ 
sized  a  composite  picture  of  the  automotive  enterprise  in  2001.  From  that  scenario, 
elements  of  a  national  information  infrastructure  have  been  identified.  The  principles  that 
govern  how  this  infrastmcture  crystallizes  must  be  formed  and  ratified  prior  to  develop¬ 
ment  of  the  details.  The  high-level  needs  as  identified  by  the  automotive  vision  for  200 1  are 
given  below  without  the  technical  details  that  are  required  for  realization.  The  implications 
are  derived  from  the  principles  which,  in  turn,  are  derived  from  the  business  vision. 

By  the  year  2001,  an  information  processing  system  to  support  the  automotive 
enterprise  will  be  very  different  from  what  we  have  today.  The  systems  of  today  are  static. 
Once  they  are  configured  for  interconnections,  data  storage,  and  processing  capability,  they 
are  not  easily  changed.  The  system  of  2001  must  be  dynamic,  easily  reconfigurable  to  allow 
new  paths  of  information  flow  and  new  types  of  information.  It  should  allow  remote  data 
access  and  processing.  The  information  system  must  allow  and  enforce  high  degrees  of 
security  and  allow  communications  across  applications  as  well  as  between  users. 

A  very  important  concept  is  the  need  for  the  information  infrastructure  to  assist  cor¬ 
porate  and  enterprise  globalization.  Today,  every  North  American  automobile  manufactur¬ 
er  has  international  operations.  Also,  the  look  of  automobile  manufacturing  in  the  United 
States  is  taking  on  an  international  character  as  more  transplants  appear.  Thus,  the  use  of 
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international  standards  in  communication  and  data  representation  is  a  requirement  of  the 
National  Information  Infrastructure. 

Due  to  the  distributed  nature  of  the  business  enterprise  of  the  future,  the  information 
system  needs  to  be  a  distributed  national  information  infrastructure  that  will  provide  a  wide 
range  of  services  that  can  be  accessed  remotely  on  an  owned,  leased,  or  usage  basis.  A 
National  Information  Infrastructure  could  be  viewed  as  a  new  utility.  Upon  this  utility  a 
whole  new  layer  of  service  suppliers  will  emerge,  providing  one  or  more  services  to  differ¬ 
ent  companies.  The  services  required  to  support  the  automotive  enterprise  vision  for  2001 
include  communications,  data  storage  and  management,  processing,  security,  presentation 
and  costing. 

C.22.1  Communications  Services 

Communication  services  will  allow  automated  information  flow  between  different 
locations  and  different  organizations.  The  communication  service  will  have  to  transfer  huge 
amounts  of  data  rapidly  and  inexpensively  if  it  is  to  be  used.  Various  media  will  implement 
the  communications  network:  satellite,  optical  flber,  radio,  and  wire.  The  network  will  be 
engineered  to  satisfy  fault  tolerance,  cost,  and  bandwidth  requirements. 

Due  to  the  foreseen  continuous  development  and  dissolution  of  permanent  product 
teams,  or  a  constantly  changing  and  dynamic  “virtual"  corporation  of  ntanufacturers,  sup¬ 
pliers,  dealers,  and  service  providers,  the  information  infrastructure  must  be  capable  of  pro¬ 
viding  and  breaking  communication  links  for  all  the  business  functions  requiring  data 
exchange  and  processing.  The  information  infrastructure  will  need  multiple  nodes  and  flex¬ 
ibility  for  responding,  altering,  adding,  and  deleting  linkages. 

The  communication  services  will  have  to  be  extremely  reliable  as  any  interruption 
in  service  will  necessarily  cause  disruption  throughout  the  enterprises  dependent  on  it  The 
information  must  be  transmitted  quickly  in  order  to  realize  the  rapid  delivery  car  and  to 
achieve  shorter  concept  to  market  time. 

Communication  will  occur  in  two  basic  ways.  Vast  amounts  of  data  will  be 
exchanged  between  organizations  that  may  then  do  some  local  or  internal  processing  of  the 
data,  and  communications  across  applications  will  occur  as  more  parallel  processing  of 
information  becomes  necessary.  Examples  of  simple  data  exchange  related  to  the  auto 
industry  in  2001  are  new  car  order  data,  supplier  scheduling,  and  vehicle  traceability  infor¬ 
mation.  Possible  use  of  inter-application  communications  could  be  new  car  orders  interact¬ 
ing  with  supplier  scheduling,  accounting  processes,  and  transportation  services. 
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More  complex,  high-volume  information,  such  as  geometric  models  for  product 
design  and  process  plans  for  automated  manufacturing,  will  also  have  to  flow  between 
organizations.  This  flow  is  necessary  to  allow  more  effective  use  of  outside  design  and 
engineering  services,  shorten  the  design  life  cycle,  and  provide  automated  support  for  con¬ 
current  engineering.  A  variety  of  design  representations  will  have  to  be  accommodated, 
such  as  lines,  frame,  and  solid  CAD  representation. 

There  are  multiple  schools  of  thought  on  how  data  should  be  used  and  exchanged: 
common  data  representation  and  data  interpretation.  The  first  view  espouses  development 
and  use  of  a  common  data  representation.  A  parallel  to  this  is  the  use  of  English  as  a  com¬ 
mon  language  where  everyone  using  the  language  knows  the  meaning  of  each  word  in  it. 
The  second  view  allows  each  organization  to  use  its  own  language  or  data  representation 
as  it  sees  fit,  with  data  exchange  being  possible,  and  to  provide  interpretation  services  to 
translate  the  “remote”  representation  into  the  “local”  representation  required  for  use.  In  the 
third  view,  translations  are  always  between  the  local  language  and  the  universal  one,  thus 
requiring  fewer  translations  than  the  second  view  and  causing  less  internal  disruption  than 
the  first. 

Over  the  long  run,  development  of  a  common  data  representation  will  probably  be 
the  most  cost  effective  for  two  reasons.  First,  new  interpreters  will  not  be  required  as  new 
organizations  and  information  systems  develop.  Second,  interpretation  will  require  sub¬ 
stantial  computing  power,  but  will  add  no  real  value  to  the  data.  The  collection  of  data  mod¬ 
els  can  be  enlarged  without  loss  of  usefulness  of  those  already  in  use.  However,  the 
common  representation  approach  requires  consensus  and  standards  for  data  representation. 
The  inffastructure  will  then  allow  mutual  definition  and  exchange  of  feature  data  by  multi¬ 
ple  manufacturers  and  suppliers  using  standard  terminology  and  exchange  formats. 

C.2,2.2  Data  Storage  and  Management  Services 

The  information  infrastructure  must  provide  capability  for  distributed  data  storage, 
local  data  storage,  and  large  data  repositories.  A  much  greater  amount  of  data  will  be  stored 
as  well  as  transferred  than  is  processed  today.  The  automotive  vision  for  2001  suggests 
automated  design  processing,  virtual  reality  representations  rather  than  physical  mock-ups 
and  prototypes,  computerized  process  plans,  storage  of  designs  for  future  use,  knowledge- 
based  systems  for  worker  support  and  enhanced  productivity,  and  many  other  techniques 
requiring  high  volumes  of  computer  data.  Additionally,  the  data  will  have  to  be  accessed 
by  a  number  of  organizations  within  the  enterprise.  The  service  will  have  to  provide  secu- 


rity  against  unauthorized  access,  ensure  data  integrity,  and  ensure  reliability  so  that  no  data 
will  be  lost. 

Data  storage  services  must  provide  usable,  accessible,  and  easily  updatable  libraries 
of  designs,  parts,  concepts,  and  features  that  can  be  recalled  and  used  in  new  applications. 
Such  libraries  will  help  realize  shorter  design  life  cycles  and  aid  in  using  modular  and  inter¬ 
changeable  subsystems  in  the  design  of  a  new  vehicle  or  custom  vehicle. 

Data  management  services  will  provide  maintenance,  archiving,  and  compression 
of  files  for  storage  and  archival  services.  These  functions  are  typically  performed  transpar¬ 
ently  as  system  overhead  tasks. 

Data  management  services  must  provide  reliable  transfer  and  update  of  information 
in  a  timely  manner.  The  system  will  have  multiple  levels  of  develop,  read,  alter,  and  retain 
features  that  allow  simultaneous,  continuous  design  and  updating  by  multiple  concurrent 
engineering  teams. 

C.2^.3  Processing  Services 

Data  processing  includes  the  three  basic  functions  of  modeling,  simulation,  and  cal¬ 
culation.  Today  some  processing  services  are  purchased  (for  example,  payroll  processing). 

In  ten  years,  processing  will  become  increasing  complex  as  more  functions  of  a 
business  enterprise  use  automated  information  processing  and  more  application  environ¬ 
ments  exist.  Modeling  will  occur  for  all  aspects  of  the  business,  including  simulations  and 
virtual  reality  used  for  marketing.  CAD/CAM/CIM  will  become  common  in  the  automo¬ 
tive  enterprise,  and  the  infrastructure  must  seek  to  maximize  the  utility  of  that  linkage 
between  design  and  manufacture. 

Economies  of  scale  will  dominate  decision-making  processes.  Automotive  compa¬ 
nies  must  become  sensitive  to  and  make  decisions  based  on  manufacturing  smaller  num¬ 
bers  of  a  certain  model.  This  shift  will  create  a  need  for  new  accounting  processes,  which 
will  be  another  service  for  use  by  companies  within  the  enterprise.  Accounting  services  will 
be  a  tool  for  controlling  as  well  as  calculating  costs,  requii’'''*  activity-based  accounting 
and  control  of  cost  drivers  through  an  integrated  information  system. 

The  information  infrastructure  will  contain  computerized  systems  for  simulating 
prototype  tests  ranging  from  preliminary  safety  and  crash  tests  to  fuel  efficiency  simula¬ 
tions. 
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It  may  not  be  cost  effective  for  every  automotive  enterprise  or  supplier  organization 
to  develop  the  complex  models  and  algorithms  needed  to  perform  these  tasks,  even  though 
they  will  be  required  to  stay  competitive.  The  information  infrastructure  will  provide  the 
means  of  accessing  the  more  complex  processing  services  on  an  “as  needed”  basis.  In  this 
way,  both  large  automotive  OEMs  and  small  suppliers  will  benefit  from  these  processing 
capabilities.  The  OEMs  and  first-tier  suppliers  can  focus  their  efforts  more  on  the  process 
of  making  cars  and  less  on  ancillary  support  activities.  Sub-tier  suppliers  and  smaller  com¬ 
panies  within  the  automotive  enterprise  will  benefit  from  being  able  to  access  processing 
capabilities  that  they  would  not  be  able  to  afford  otherwise. 

\  new  processing  service  identified  during  the  development  of  the  automotive 
vision  for  2001  is  a  market-sensing  activity  that  will  continuously  scan  the  demographics 
and  needs  of  the  auto  user  community  and  the  options  available  to  fulfill  those  needs,  poten¬ 
tially  including  cost-benefit  information  on  options. 

Order-processing  services  are  another  potential  application  for  a  National  Informa¬ 
tion  Infrastructure  and  the  services  it  might  provide.  In  the  automotive  enterprise  of  the 
future,  the  process  of  purchasing  a  vehicle  may  be  quite  different.  In  addition  to  having  a 
dealer  for  one  or  a  limited  number  of  brands  there  may  be  a  central  sales  site  for  many  or 
all  vehicle  brands.  In  this  case,  order  processing  becomes  more  complex,  and  probably  can¬ 
not  be  directly  handled  by  the  automotive  OEMs.  An  intermediate  service  may  be  required. 

C22A  Security  Services 

As  processing  and  data  storage  become  distributed  and  information  systems  con¬ 
nected  to  the  information  infrastructure  become  more  open,  security  becomes  an  increas¬ 
ingly  important  issue.  Control  of  data  access  will  be  needed  for  new  product  model 
information,  critical  marketing  data,  business  strategies  and  planning,  employee  records, 
process  planning,  and  otlicr  data  of  a  proprietary  nature.  In  the  automotive  scenario  of  200 1 , 
proprietary  data  will  have  to  be  accessible  by  people  in  many  organizations  without  sacri¬ 
ficing  control  and  security.  Security-by-view  is  a  concept  that  needs  to  be  developed  for 
control  of  large  databases. 

Another  security  service  that  will  be  desirable  for  data  exchange  will  be  high-per¬ 
formance  encryption  services.  The  information  infrastructure  must  provide  security  servic¬ 
es  that  ensure  data  integrity  and  ownership  protection  of  data. 
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C.2.2.5  Presentation  Services 

As  the  automotive  vision  for  2001  developed,  people  issues  kept  surfacing.  As  auto¬ 
mated  information  processing  becomes  part  of  everybody’s  job,  the  human  interface  issues 
must  be  addressed.  The  complexity  of  the  processing  for  the  vision  also  indicates  that 
human  interfaces  must  go  beyond  alphanumeric  displays  and  keypad  or  push-button 
entries. 

The  infrastructure  must  include  proper  information  presentation,  including  various 
means  of  aggregation  and  display  that  allow  immediate  comprehensible  and  system-wide 
incorporation  of  new  information.  For  example,  if  features  are  modified  during  the  design 
process,  an  information  system  must  ensure  that  this  type  of  data  is  immediately  transmitted 
to  the  proper  entities  in  an  understandable  and  relevant  manner.  Hypermedia  can  be  one 
means  to  this  end. 

Presentation  services  available  firom  third  parties  can  address  this  issue.  Standards 
for  information  presentation  and  interface  will  aid  in  solving  this  problem,  and  the  use  of 
standards  will  make  people  more  flexible  and  aid  in  developing  cross-disciplinary  skills.  As 
one  learns  new  capabilities  on  an  information  system,  the  effort  to  learn  new  interface  pat¬ 
terns  will  be  minimal  with  the  use  of  common  interfaces. 

Presentation  services  will  also  include  the  use  of  graphics  and  text  to  convey  infor¬ 
mation.  The  information  infirastructure  must  acconunodate  three-dimensional  math-based 
CAD  information  systems  coupled  with  advanced  graphics  packages  to  show  potential 
designs  and  to  simulate  potential  drive  features  and  passenger  interface  features  of  vehicles. 

C.22,6  Costing  Services 

The  information  system  should  be  a  managed  organizational  resource  for  enhanced 
and  explainable  decisions  and  coordination.  Costing  of  these  information  resources  and 
services  will  be  an  important  issue.  Managers  want  to  know  if  the  use  of  outside  services, 
rather  than  internal  development  and  maintenance,  will  be  cost  effective.  The  information 
infrastructure  will  need  to  support  the  costing  of  services  with  respect  to  the  scope  of  spec¬ 
ified  work  (Table  C-4). 

The  need  for  a  National  Information  Infrastructure  is  becoming  more  and  more 
apparent  as  enterprises  rethink  their  business  strategies  and  develop  new  partnerships  and 
product  teams.  Automated  information  processing  and  storage  will  become  increasingly 
important  to  maintain  combativeness  of  product,  cost,  and  quality.  People  in  every  sector 
of  the  workforce  will  interface  with  information  systems.  Common  data  will  have  to  be 
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Table  C-4.  Services  to  Support  the  Automotive  Enterprise 


PRODUCT 

MARKETING/ 

CONCEPT 

DESIGN 

PRODUCT/ 

PROCESS 

DESIGN 

OPERATIONS/ 

STORAGE 

COMMUNICA¬ 

TIONS 

traceability; 
smart  highways; 
rapid  delivery 
car;  shorter  life 
cycle. 

demographic; 
hypermedia  mar¬ 
keting;  concept 
costing;  distribut¬ 
ed  teams;  short¬ 
er  life  cycle; 
quick  design 
changes. 

integrated  pro¬ 
gram  teams;  rapid 
dissemination  of 
design  change 
informatbn. 

scheduling;  trace- 
ability;  service 
feedback  to  manu¬ 
facturing;  control 
room  monitoring  of 
process;  batches 
of  one. 

DATA  STORAGE 
AND 

MANAGEMENT 

traceability,  qual¬ 
ity  control  (QC); 
lot  tracking;  com¬ 
pression;  updat¬ 
ing  trace  data; 
customized 
design. 

“concepts  on  a 
shelf”;  proto¬ 
types;  lessons 
learned;  reus¬ 
able  subsystem 
designs;  previ¬ 
ous  design 
retrieval;  con¬ 
cept/cost  rela¬ 
tionships; 
version  mainte¬ 
nance;  design 
data  compres¬ 
sion  and  recy¬ 
cling. 

archive  of  design  & 
process  plan;  store 
lessons  learned; 
continuous 
improvement  (Cl); 
retooling;  repro¬ 
gramming;  store 
design  intent;  rapid 
retrieval  of  stored 
data;  version  con¬ 
trol;  compression 
for  efficiency;  mod¬ 
ular  subsystems. 

knowledge-based 
maintenance; 
knowledge-based 
workers;  service 
records;  traceabili¬ 
ty;  archival;  engi¬ 
neering  change 
management;  pro¬ 
cess  plan  back¬ 
ups;  lot  tracking. 

PROCESSING 

software  content; 
program  fea¬ 
tures;  rapid  deliv¬ 
ery  car. 

hypermedia  mar¬ 
ket  tests;  con¬ 
cept  cost 
development; 
simulations; 
demographic 
studies;  prelimi¬ 
nary  CAFE  and 
safety  simula¬ 
tion;  regulatory 
cross-checks. 

joint  product/pro¬ 
cess  design;  pro¬ 
cess  simulation; 
real-time,  closed 
loop  control;  CAD/ 
CAM  realization; 
rapid  tooling;  con¬ 
tinuous  cost 
improvements; 
activity-based 
accounting. 

production  con¬ 
trol;  process  con¬ 
trol;  parallel  order 
processing;  JIT 
scheduling;  scher* 
ule  leveling; 
accounting/admin¬ 
istrative  reports; 
service/dealer 
feedback  to  pro¬ 
cess. 

SECURITY 

prevent  unautho¬ 
rized  access; 
encryption  of 
design  and  mar¬ 
keting  data  prior 
to  transmittal. 

owner  protection; 
prevent  unautho¬ 
rized  access; 
maintain  process 
competitive  edge; 
encryption  of 
design  data. 

prevent  unautho¬ 
rized  access;  per¬ 
sonnel  record 
integrity;  customer 
privacy. 

PRESENTATION 

virtual  reality; 
simulatbns; 
hypermedia  for 
marketing;  cost 
analysis  reports. 

cross-disciplinary 
representation; 
good  operator 
interface  develop¬ 
ment. 

cross-business 
function  report 
generation;  man¬ 
agement  by  infor¬ 
mation. 

accessed  by  many  people  in  multiple  organizations.  Data  will  be  accessed  and  stored  local¬ 
ly,  in  distributed  fashion,  and  within  large  data  repositories.  Open  systems  and  a  common, 
high-speed  communication  network  will  be  needed  as  the  backbone  of  the  information 
infrastructure. 

National  and  international  standards  governing  data  representation,  exchange,  and 
transmittal  must  be  in  place  to  facilitate  the  effective  and  efficient  use  of  the  information 
infrastructure.  Use  of  proprietary  systems  and  standards  will  not  facilitate  the  formation  of 
virtual  corporations  and  automotive  enterprises  that  will  be  able  to  compete  in  the  interna¬ 
tional  marketplace  of  200 1 . 

The  information  utility  and  services  must  be  available  to  all  organizations  involved 
in  each  automotive  enterprise.  Complex  data  processing  services  and  data  repositories  will 
allow  large  and  small  firms  alike  access  to  technologies  that  might  otherwise  be  prohibitive. 
A  whole  new  sector  of  service  providers  will  emerge  to  provide  these  services  in  the  most 
cost-effective  manner.  Cooperation  and  information  sharing  will  be  achieved  by  standard¬ 
ization  of  data  representations,  modeling  methodologies,  and  a  fast,  reliable  transport  net¬ 
work. 

C.3  ISSUES  AND  BARRIERS 

Our  description  of  the  state  of  current  automotive  industry  activities  in  1 99 1  and  the 
delineation  of  a  vision  for  2001  generated  some  areas  of  concern  among  the  project  team, 
the  people  interviewed,  and  the  panel  members  who  participated  in  the  vision-setting 
roundtable  discussions.  Those  concerns  reflect  issues  that  need  to  be  addressed  and  barriers 
in  the  existing  organizational  and  information  infrastructure  environments  to  achieving  the 
vision.  Some  of  those  barriers  are  technical.  However,  it  was  a  consensus  that  technology 
is  not  the  barrier  to  the  vision.  Rather,  the  principal  barriers  lie  in  people:  their  skills,  atti¬ 
tudes,  and  general  resistance  to  change.  The  barriers  were  cast  by  our  roundtable  panelists 
as  “qualifiers”  underlying  the  successful  implementation  of  the  Automotive  Industry  2001 
vision  and  its  accompanying  information  infirastmcture. 

C.3.1  GOALS  AND  ECONOMIES  OF  SCALE 

North  American  auto  companies  seem  to  be  striving  to  keep  pace  with  or  catch  up 
to  the  Japanese.  It  is  widely  acknowledged  that  Japan  knows  what  it  wants  and  is  organized 
to  attain  it.  North  American  industry  appears  to  lack  any  clear  goal  of  excellence  in  the 
sense  of  surpassing  the  Japanese  and  learning  from  the  broader  base  of  international  man¬ 
ufacturing  models,  especially  European  ones. 
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North  American  automotive  manufacturers  tend  to  think  “big  change”  and  “quick 
results.”  The  vision  emphasis  on  bounded  customization  suggests  a  need  to  redress  compa¬ 
ny  perspectives  in  the  form  of  several  sets  of  smaller-scale  niche  markets  and  lower- volume 
production.  An  emphasis  on  continuous  improvement,  rather  than  a  “big  bang”  view  of 
change,  would,  for  example,  helps  to  overcome  problems  of  staff  continuity  on  design 
teams,  which  Honda  appears  to  have  solved  constructively. 

C.3,2  MANAGEMENT  ACTION  AND  LEADERSHIP 

Organizational  tradition,  size,  and  rigidity  may  limit  management  leadership’s  abil¬ 
ity  to  achieve  the  vision.  Leadership  needs  to  solve  problems  associated  with  long-term 
planning,  championship  of  new  infrastructures,  and  supportive  organizational  cultures  to 
link  information  structures  with  business  enterprise  goals. 

Mthin  firms,  the  barrier  is  characterized  by  less  than  optimal  structuring  and  pro¬ 
cesses  to  support  the  vision.  Insufficient  attention  has  yet  been  focused  on  teams  for  infor¬ 
mation  exchange  and  use,  solution-oriented  task  definition,  and  thorough,  open  processes 
for  effective  communication.  Units  in  joint  planning  activities  typically  fail  to  mesh  with 
each  other  or  worse,  bottleneck  the  process. 

Beyond  the  boundaries  of  firms,  partnerships,  where  they  exist,  are  pretty  much  top- 
down  arrangements,  wherein  the  OEM  “owns”  the  partner,  or  the  partners  are  brought  into 
processes  (e.g.,  design)  late  or  without  sufficient  information  and  tools  to  participate  effec¬ 
tively. 

There  is  a  lack  of  incentives,  encompassing  the  entire  product  and  partnership 
spans,  by  which  people  can  be  rewarded  for  their  contributions  as  team  members  to  differ¬ 
ent  phases  and  functions  of  the  product. 

C.3.3  LACK  OF  AN  ENTERPRISE  CONCEPT 

The  industry  lacks  principles  of  enterprise  integration.  By  principles,  we  mean  a 
philosophy  of  information  system  objectives  for  technology  and  its  management  driven  by 
common  values.^*  Those  principles  would  apply  to  different  components  of  the  overall 
architecture,  including  the  infrastructure  (hardware,  software,  and  communications),  data. 


*  *  PRISM.  Dispersion  and  Interconnection:  Approaches  to  Distributed  Systems  Architecture.  Final  Report  of 
the  Partnership  for  Research  in  Information  Systems  Management  (PRISM)  Project  by  Index  Systems,  Inc. 
and  Hammer  and  Company,  Inc.,  June  1986. 
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applications,  and  organization.  Example  principles  would  be  “We  are  committed  to  a  multi¬ 
vendor  environment”  or  “Applications  will  be  processed  where  the  data  reside.” 

Perhaps  even  more  fundamental  than  principles  for  integration  is  the  lack  of  initial 
definitions  of  the  enterprise.  The  vision  supports  the  concept  of  enterprises  as  “virtual  cor¬ 
porations”  of  250  or  more  companies.  But  the  particular  elements  of  the  enterprise  and  their 
roles  need  to  be  clearly  specified.  The  present  situation  suggests  that  companies  can  inte¬ 
grate  but  enterprises  cannot.  For  that  to  happen,  the  enterprise  has  to  be  defined  and  its 
infrastructure  has  to  be  built. 

C.3.4  UNREALIZED  TECHNOLOGY  OPPORTUNITIES 

New  technologies  for  design,  marketing,  and  linking  information  to  the  business 
enterprise  are  not  being  fully  used,  partly  due  to  the  problem  of  legacy  systems.  Legacy  sys¬ 
tems  tend  to  “hang  on”  because  they  represent  significant  pieces  of  organizational  turf  and 
massive  investments  in  staff  and  dollars.  Users  often  may  not  know  how  much  of  a  legacy 
system  is  really  being  used  in  today’s  applications. 

The  resistance  to  change  and  investment  may  impede  new  marketing  and  design 
concepts  such  as  virtual  reality,  hypermedia,  advanced  prototyping,  and  dealer  involve¬ 
ment.  There  is  insufficient  risk  taking  for  innovation.  Legacy  systems,  coupled  with  suppli¬ 
ers’  needing  to  maintain  multiple  design  (CAD)  systems,  limit  basic  awareness  of  new 
technologies  or  applications. 

C.3,5  LACK  OF  A  SUFnCIENT  INFORMATION  NETWORK 

The  United  States  lacks  a  national  high-speed  information  network  that  can  dynam¬ 
ically  link  the  elements  of  the  auto  enterprise.  Constructing  such  a  network  poses  logistical 
problems.  Installation  will  be  expensive.  Network  reliability  issues  need  to  be  solved. 
Schemes  for  error  detection,  fault  detection  redundancy,  or  other  fault  tolerant  approaches 
need  to  be  chosen.  Network  management  for  handling  different  and  increasing  volumes  of 
data  with  appropriate  security  must  be  developed.  Governing  principles  of  a  national  data 
transmission  resource  will  be  required.  Network  accounting  methods  have  to  provide  for 
fair  and  economic  cost  burdens  on  the  users. 

C.3.6  LACK  OF  INFORMATION  STANDARDS 

There  are  no  standards  for  a  high-speed,  high-volume  transmission  infrastructure. 
Some  standards  development  is  underway,  especially  in  the  area  of  product  data  definition 
and  exchange.  However,  greater  progress  and  application  protocol  development  are  need- 
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ed.  Plans  for  internationalizing  the  data  exchange  in  a  high-speed  network  are  needed. 
North  American  automotive  companies  lack  international  standards  to  which  they  believe 
they  can  comply  while  protecting  their  advantage  in  a  competitive,  capitalist  society.  They 
need  to  realize  that  their  competitive  advantage  resides  in  how  they  use  a  system  rather  than 
in  the  abstract  features  that  it  processes. 

C.3.7  THE  PROBLEM  OF  ARCHIVING  AND  THE  LACK  OF  TOOLS 

While  we  earlier  suggested  a  barrier  associated  with  unwillingness  to  invest  suffi¬ 
ciently,  there  is  also  a  current  mode  of  not  saving,  archiving,  storing,  and  protecting  infor¬ 
mation  for  later,  as  yet  unspecified,  uses.  Companies  typically  do  not  archive  and  store 
design  information,  oi,  when  they  do,  it  “goes  stale.”  This  difficulty  is  also  related  to  a  lack 
of  true  concurrent  engineering  with  the  early  participation  of  all  the  players  in  design  and 
manufacturing  planning.  Architectures  and  methods  for  concurrent  engineering  are  being 
developed,  but  firms  will  also  need  more  tools  for  design  and  manufacture  that  embody 
standards,  appeal  to  users,  and  contribute  significantly  to  applications. 

C.3.8  FEW  VISIBLE  SUCCESS  STORIES 

To  make  the  vision  happen  throughout  the  industry,  success  stories  of  attained  ben¬ 
efits  will  go  a  long  way  toward  motivating  firms  and  people  to  embrace  enterprise  integra¬ 
tion  and  new  information  infrastructures.  But  there  are  few  cases  of  really  broad,  multi¬ 
company  integration,  or  at  least  few  that  are  being  publicly  reported.  It  has  been  suggested 
that  enterprise  integration  can  reduce  TTM  by  30%,  and  design  cost  by  20%.  Stories  like 
GM’s  SATURN  and  Chrysler ’s  Grand  Cherokee  need  to  be  told. 

C.4  RECOMMENDATIONS 

Even  though  the  primary  role  of  IDA  documents  is  to  analyze  issues  for  and  make 
recommendations  to  entities  within  the  Department  of  Defense,  the  auto  industry  partici¬ 
pants  in  this  study  felt  that  recommendations  to  their  industry  are  warranted  and  would  be 
helpful.  The  following  recommendations  are  a  distillation  of  thoughts  from  the  industry 
visits  and  the  roundtable  panel.  They  do  not,  however,  necessarily  represent  an  industry 
consensus.  They  reflect  our  suggestions  for  what  the  automotive  companies  and  suppliers 
could  do  to  foster  the  success  of  the  vision  for  2001.  These  activities  could  be  done  inde¬ 
pendently  of,  but  also  in  support  of,  potential  actions  by  the  government  to  enhance  the 
information  infrastructure  of  the  future.  Tliese  recommendations  go  beyond  the  specific 
information  infrastructure  implications  of  the  vision  to  address  broader  organizational  and 
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enterprise  implications  of  the  linked  business  rationale  and  infrastructure.  The  recommen¬ 
dations  address  several  of  the  barriers  described  in  the  previous  chapter. 

Strengthen  or  expand  the  culture  of  the  organization  to  accommodate  visions, 
people,  and  practices  for  integration. 

•  Define  and  embrace  a  vision^  with  global  strategies  and  a  basis  for  common 
mechanics  of  operation.  Maintain  company  leadership,  commitment,  and 
championship  of  the  enterprise  to  make  the  vision  happen.  Focus  management 
planning  more  on  process  capabilities  than  short-term  results.  Delegate  key 
decisions,  such  as  prototype  go/no-go  to  functional  experts.  Engender  self-  and 
team-based  discipline  to  act  and  move  forward. 

•  Base  the  organizational  culture  on  true,  meaningful,  and  practical  partnerships 
among  actors  in  the  auto  enterprise,  developing  and  implementing  partnerships 
for  strategy  and  activities  both  within  the  boundaries  of  the  organization  and 
outside  it  in  its  enterprise  network.  Partnerships  mean  early  and  thorough  life 
cycle  involvement  of  multiple  sets  of  players  in  the  enterprise:  cross-functional 
teams  within  the  organization,  employees  and  (especially  mid-level  and  pro¬ 
gram)  managers,  customers,  dealers,  and  suppliers  at  all  levels  in  the  design  and 
production  chain.  Partnerships  will  accommodate  the  coexistence  and  coopera¬ 
tion  of  autonomous  and  interrelating  organizations. 

•  Focus  and  accelerate  progress  towanl  manageable  sets  of  objectives,  but,  at  the 
same  time,  embrace  long-term  perspectives  in  setting  goals  and  anticipating 
results.  Adopt  or  maintain  perspectives  and  incentives  for  change  throughout 
the  organization  and  continuous  improvement  of  the  product  and  the  company. 
Involve  people  in  continuous  improvement  efforts.  Focus  on  integrating  human 
capabilities,  with  integration  being  the  major  focus  of  computer-integrated 
manufacturing  (CIM). 

•  Treat  people  as  fixed  assets  rather  than  variable  costs  in  the  partnership:  fully 
utilize  human  capabilities  in  the  array  of  organizational  tasks,  delegate  respon¬ 
sibilities,  and  trust  knowledge-based  decisions  below  senior  management.  Rec¬ 
ognize  and  use  the  expanding  roles  of  engineers  and  operational  staff  in 
planning  and  execution.  At  the  same  time  one  is  recognizing  and  fiilly  utilizing 
people’s  talents,  the  firm  must  also  prepare  to  cope  with  the  increasing  tran¬ 
sience  of  employees,  moving  more  rapidly  within  and  outside  the  firm.  Compa- 
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nies  might  consider  franchising  some  facets  of  indirect  labor,  such  as  selected 
functions  of  administration,  finance,  and  human  resources. 

•  Incorporate  as  part  of  the  culture  a  results-  and  process-based  interest  in  really 
sharing  irtformation,  not  just  passing  data.  This  process  will  involve  developing 
or  maintaining  structures  and  senses  of  teamwork  within  the  organization  and 
mutual  interdependencies  on  information  and  communication.  Maintaining  the 
sharing  culture  will  also  require  developing  mechanisms  for  sharing  and/or  pro¬ 
tecting  proprietary  information  elements,  such  as  may  exist  in  CAD  libraries  of 
concept  designs. 

Develop,  continue,  or  foster  organizational  systems  and  practices  to  implement 
and  sustain  the  culture. 

•  Redefine  and  establish  new  reward  systems  to  provide  incentives  for,  and  rec¬ 
ognition  of,  effective  work  related  to  integration  objectives.  Such  reward  sys¬ 
tems  should  consider  incorporating  meaningful  intrinsic  and  extrinsic  rewards 
for  knowledge-based  performance,  including  opportunities  for  dual  career  lad¬ 
ders  within  firms.  Rewards  should  be  contingent  on  vision-related  performance 
of  individuals  and  teams,  and  the  substance  of  rewards  should  be  sufficiently 
flexible  to  accommodate  different  individual  interests. 

•  Implement  structures  for  coordinating  interrelating  functional  units  so  as  to 
facilitate  workflow,  information  transmission,  and  information  use.  Provide 
those  structures  with  people  having  capabilities  to  act  as  team  members  and  to 
use  information  tools.  Embed  those  structures  and  processes  in  the  culture  for 
continuing  commuiucation  and  decision  making. 

•  Establish  major,  identifiable  functions  for  managing  supplier  development  and 
relations.  All  levels  of  the  supplier  chain  in  the  enterprise  need  to  be  recognized 
and  their  information  needs  accommodated  in  a  non-hierarchical  fashion,  even 
though  tiers  will  continue  to  exist  The  particular  roles  of  smaller  suppliers  can 
be  identified  to  establish  their  needs  and  mechanisms  for  including  them  in  the 
enterprise  information  structure.  For  example,  not  all  may  require  total  informa¬ 
tion  exchange  capabilities  or  common  CAD  systems.  Partnerships  with  suppli¬ 
ers  will  require  early  and  total  life  cycle  involvement  of  the  supplier 
organizations  in  product  and  process  planning. 
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•  Streamline  and  integrate  internal  design  and  operations  functions.  Team 
approaches  to  the  design  of  minimally  overlapping  tasks  can  streamline  the 

design  function  through  concurrent  engineering,  design  teams,  and  design  cen-  ^ 

ters.  Similarly,  functions  of  order  processing,  which  account  for  so  much  time 
in  the  overall  production-to-customer  cycle,  can  be  monitored  and  improved. 

Some  of  these  functions  can  be  made  more  efficient  with  continuation  of  elec- 

N 

tronic  data  exchange  for  parts  ordering  and  billing,  which  might  be  broadened  i 

beyond  the  typical  involvement  of  first- tier  suppliers. 

•  Think  “custom."  Approach  future  opportunities  for  customization  of  the  prod¬ 
uct  in  an  aggressive  manner.  Given  that  cost  and  quality  will  be  essential  for 

future  survival,  product  planning  should  increasingly  concentrate  on  gaining  ' 

competitive  advantage  through  customizing  features  of  the  product.  E)esign 
teams,  with  input  about  custonwr  demographics/needs  and  technology  capabil¬ 
ities,  can  identify  ways  and  niches  for  customization  and/or  user  programmabil¬ 
ity  of  components,  features,  and  options.  Bound  the  customization  for  economy  * 

in  terms  of  market  demographics  and  customer  demands. 

•  Computerize  as  much  of  the  design-production-reuse  life  cycle  as  possible. 

Continued  efforts  toward  functional  automation  involve  embracing  the  technol¬ 
ogy  of  virtual  reality  for  elements  of  marketing,  design,  and  prototyping. 

Develop  and  implement  appropriate  and  refined  information  infrastructures 
to  accommodate  the  business  strategies,  visions,  and  practices  of  the  enterprise. 

•  Company  progress  toward  next-generation  information  infrastructures  can  be  * 

assisted  by  focusing  on  the  information  infrastructure  implications  briefly 

described  in  the  previous  section  of  our  report. 

•  The  infrastructure  should  focus  on  company  and  enterprise  commonalities,  in  ^ 

terms  of  common  systems  for  engineering,  common  mechanisms  for  integrating 
autonomous  interacting  units,  coordinated  databases,  and  common  platforms 

and  standards. 

•  The  infrastructure  must  emphasize  flexibility  for  design  and  production  activi-  < 

ties  throughout  the  enterprise,  so  that,  for  example,  suppliers  can  deal  with  CAD 
requirements  for  multiple  customers  without  investing  in  multiple  CAD  sys¬ 
tems  or  foregoing  all  legacy  systems. 


C-40 


•  The  infrastructure  should  also  focus  on  fully  utilizing  the  CAD-CAM  linkage  for 
transfer  of  information  from  design  to  production.  This  priority  may  involve 
establishing  structural  mechanisms  in  the  enterprise  for  facilitating  change  and 
development  of  new  interchange  nodes  and  processes  in  the  information  sys¬ 
tem. 

Auto  companies  can  coordinate  their  efforts  to  influence  each  other’s  and  soci¬ 
ety’s  practices  toward  integrated  enterprises  and  information  systems. 

•  Companies  can  push  further  and  faster  development  of  guidelines  and  practices 
by  the  AIAG  and  various  trade  associations  contributing  to  the  development  of 
the  supplier  base,  including  the  National  Tooling  and  Machining  Association 
(NTMA),  the  Society  for  Plastics  Industries,  the  Precision  Metalforming  Asso¬ 
ciation,  the  Advanced  Manufacturing  Technology  (AMT),  the  American  Man¬ 
agement  Association,  and  the  American  Society  for  Training  and  (development 

•  Companies  can  form  groups  or  committees  to  act  together  on  areas  of  common 
interest  Cross-company,  within-industry  groups  can  be  established  and  main¬ 
tained  in  auto  (as  well  as  aerospace  and  electronics)  for  developing  innovations 
in  interconnected  functions  of  purchasing,  engineering,  management,  etc.  Coor¬ 
dinated  efforts  can  also  occur  or  be  expanded,  as  in  the  National  Center  for  Man¬ 
ufacturing  Sciences  (NCMS)  model,  to  deal  with  new  technologies  or 
processes,  as  is  the  case  for  battery  technology  and  advanced  composite  mate¬ 
rials.  Company  consortia  should  be  provided  with  the  necessary  resources, 
proper  mix  of  interests  and  competencies,  and  authority  to  get  things  done.  Con¬ 
sortium  members  should  be  empowered  to  speak  for  their  companies,  and  tech¬ 
nically  grounded  in  the  objectives  of  the  consortium. 

•  Companies  can  sustain  concerted  effort  to  influence  development  of  standards 
and  bring  about  government  support  for  improved  information  infrastructures. 
Auto  companies  can  expand  their  involvement  in  emerging  standards  defini¬ 
tions  such  as  IGES  and  PDES  efforts  by  the  ANSI,  the  ISO,  and  related  organi¬ 
zations.  They  can  also  lobby  for,  present  a  unified  business  rationale  for,  and 
help  to  define  the  parameters  of  a  government  initiative  for  a  national  high¬ 
speed  information  network. 

•  Coordinated  company  efforts  can  also  be  directed  to  education  and  training  to 
develop,  implement,  and  use  new  information  infrastructure  components. 
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Through  federal  and  local  governments,  educational  institutions,  and  profes¬ 
sional  associations,  auto  companies  can  influence  the  development  and  mutual 
awareness  of  cross-functional  and  new  skill  repertoires  for  management  and  the 
workforce.  People  in  the  auto  industry  of  2001  are  going  to  have  to  be  “cross 
skilled,”  but  not  to  the  point  of  being  abstract  “generalists.”  Enhanced  company 
training  and  educational  programs  from  kindergarten  through  post-secondary 
institutions  should  bring  about  greater  and  more  diverse  knowledge.  As  noted 
by  one  of  our  contributors,  David  Cole,  management  of  that  expanded  knowl¬ 
edge  base  will  be  one  of  the  keys  to  success  in  the  21st  century. 

C.5  LIST  OF  COMPANIES  VISITED 

(1)  Allison  Gas  Turbine,  Division  of  GM 

(2)  CDI/Modem  Engineering 

(3)  The  Cross  Company 

(4)  Ford  Motor  Company  of  North  America 

(5)  General  Motors 

(6)  Ryobi  Die  Casting  (USA),  Inc. 

(7)  Saturn 

(8)  University  of  Michigan,  Office  for  the  Study  of  Automotive  Transportation. 
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APPENDIX  D.  AEROSPACE  INDUSTRY  RATIONALE 


This  appendix  documents  the  cunent  state  of  enterprise  integration  in  the  aerospace 
industry  sector  and  provides  a  vision  of  where  this  industry  sector  will  be  with  respect  to 
enterprise  integration  in  the  year  2001. 

In  contrast  to  the  other  appendices,  Appendix  D  was  updated  in  1993  to  reflect  new 
information  collected  since  the  first  draft  of  the  document  was  produced  in  1991.  For  this 
reason,  this  appendix  refers  to  information  contained  in  Appendix  B,  Electronics  Rationale, 
and  Appendix  C,  Automotive  Rationale,  in  comparing  and  contrasting  the  status  and  direc¬ 
tion  of  the  industry. 

Appendix  D  has  five  sections: 

•  Aerospace  Industry  1993.  Describes  the  business  strategies  employed  to  move 
toward  enterprise  integration,  the  technical  approaches  to  entoprise  integration, 
including  the  information  infrastructures  required  to  accomplish  the  goals,  and 
a  summary  of  the  lessons  learned  to  date  regarding  a  transition  to  more  fully 
integrated  enterprises. 

•  Aerospace  Industry  200 1 .  Describes  a  vision  for  the  future  of  enterprise  integra¬ 
tion  and  the  changes  that  will  be  required  in  the  information  infrastructures  to 
support  that  vision. 

•  Issues  and  Barriers.  Summarizes  the  unresolved  problems  that  the  companies 
visited  during  the  study  have  identified.  Some  problems  are  issues  that  must  be 
addressed  within  the  individual  companies,  while  others  must  be  solved  jointly 
by  the  industry  acting  in  consensus,  and  others  require  government  action. 
Many  of  the  issues  and  barriers  identified  by  the  aerospace  companies  are  the 
same  as  those  identified  by  the  other  industry  sectors  visited. 

•  Recommendations.  Provides  recommendations  to  both  members  of  industry 
and  to  government  agencies  regarding  actions  to  be  taken  to  enable  and  facili¬ 
tate  enterprise  integration 
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•  List  of  Companies  Visited. 


D.l  AEROSPACE  INDUSTRY  1993 

The  following  aerospac  companies  were  visited  during  1991  and  again  during 

1993: 

•  General  Electric  Aircraft  Engine  Division,  Cincinnati,  OH 

•  Lockheed  Aeronautical  Systems,  Marietta,  GA 

•  Martin  Marietta  Missiles  Systems,  Orlando,  FL 

•  Northrop  Aircraft  Company,  Hawthorne,  CA 

•  Pratt  and  Whitney  Government  Engine  Business,  East  Hartford,  CT 

These  companies  represent  the  top  tier  or  primary  contractors  in  the  commercial 
and  military  aircraft  manufacturing  sector. 

Some  of  the  information  collected  during  these  visits  reflects  the  state  of  enterprise 
integration  within  a  particular  company.  Other  integration  efforts  were  driven  by  partner¬ 
ships  among  a  group  of  the  aerospace  companies,  and  the  information  we  collected  reflects 
this  teaming  relationship. 

Appendix  B,  Electronics  Industry  Rationale,  describes  four  characteristics  of  that 
industry  sector  that  drive  enterprise  integration  efforts:  technology,  competition,  innova¬ 
tion,  and  autonomy.  In  the  aerospace  industry,  technology  and  competition  are  also  signif¬ 
icant  factors  in  the  success  of  enterprise  integration.  However,  the  characteristics  of 
innovation  and  autonomy  as  described  in  Appendix  B  are  less  apparent.  Instead,  partner¬ 
ships  and  teaming  arrangements  and  long-lived  systems  and  safety  concerns  are  character¬ 
istics  of  particular  importance  to  the  aerospace  industry,  and  thus  drive  the  success  of  any 
integration  effort. 

These  four  characteristics  (technology,  competition,  partnerships  and  teaming 
arrangements,  and  long-lived  systems  and  safety  concerns)  assume  varying  levels  of 
importance  depending  upon  whether  the  product  being  produced  is  for  commercial  or  mil¬ 
itary  use. 

Aerospace  companies  producing  a  military  aircraft  often  push  the  state  of  the  art  in 
their  product.  This  may  require  the  adoption  of  new  technologies  to  support  the  design, 
development,  manufacture,  and  maintenance  processes  associated  with  that  product. 
Examples  of  these  technologies  include  advanced  computer-aided  design  (CAD)  systems 
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for  electronic  mock-ups,  integrated  tool  sets  and  object  management  systems,  and  electron¬ 
ic  information  exchange.  Military  products  may  also  force  companies  to  use  new  technol¬ 
ogies  through  specific  requirements  statements.  Electronic  sign-off,  Computer-Aided 
Acquisition  and  Logistics  Support  (CALS)  requirements,  and  electronic  data  interchange 
(EDI)  are  examples  of  government-imposed  requirements  that  would  drive  the  implemen¬ 
tation  of  new  technologies. 

Commercial  aerospace  companies  are  facing  severe  economic  conditions.  Fewer 
customers  for  new  aircraft  and  an  excess  of  still  viable  aircraft  now  for  sale  by  ailing  air¬ 
lines  means  that  aerospace  companies  are  both  cutting  back  production  and  trying  to  make 
that  production  more  efficient.  New  technologies  are  seen  as  one  approach  to  cutting  costs 
and  increasing  efficiency. 

With  shrinking  commercial  and  military  market,  competition  among  the  aerospace 
companies  is  increasing.  In  addition,  European  aircraft  manufacturers  now  hold  a  signifi¬ 
cant  market  share.  Subsidized  aircraft  production  in  foreign  countries  makes  it  difficult  for 
U.S.  manufacturers  to  compete.  For  this  reason,  many  companies  are  initiating  efforts,  such 
as  enterprise  integration,  that  they  believe  will  make  them  more  competitive. 

Teaming  and  partnership  arrangements  have  always  been  an  integral  part  of  the 
aerospace  industry.  The  large,  highly  complex  nature  of  the  product  requires  significant 
capital  investments  and  a  very  broad  range  of  highly  specialized  technical  competence.  It 
would  not  be  possible  for  a  single  aerospace  company  to  deliver  a  product  without  the 
involvement  of  partners  and  a  significant  number  of  subcontractors.  By  forming  partner¬ 
ships,  companies  can  enter  into  mutually  beneficial,  temporary  arrangements  that  provide 
mechanisms  to  share  the  expense,  risk,  and  potential  profit  for  a  significant  undertaking  like 
fielding  a  new  aircraft.  Enterprise  integration  supports  teaming  by  allowing  information 
sharing  and  management.  Aerospace  companies  recognize  this. 

Unlike  the  electronics  and  automotive  industries,  the  aerospace  industry  produces 
products  that  are  expected  to  have  very  long  life  times.  Aircraft  may  remain  in  service  30 
to  40  years.  Aircraft  also  have  critical  safety  requirements.  For  these  reasons,  information 
on  the  development  of  the  aircraft  must  be  managed  for  the  life  of  the  aircraft  to  support 
maintenance.  Any  changes  or  upgrades  to  the  product  must  be  carefully  developed,  then 
certified  before  they  can  be  implemented.  Commercial  and  military  aerospace  companies 
recognize  the  need  and  are  looking  for  better  ways  to  manage  the  vast  amounts  of  data  asso¬ 
ciated  with  their  products. 
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INTRODUCTION 


In  this  section  we  describe  the  rationale  used  by  the  aerospace  companies  in  deter¬ 
mining  whether  to  implement  an  enterprise  integration  effort.  We  discuss  the  real  and  per¬ 
ceived  barriers  to  an  enterprise  integration  effort  and  the  expected  benefits. 

All  of  the  aerospace  companies  we  visited  have  begun  to  define  and  implement 
enterprise  integration  programs.  These  programs  vary  widely.  The  companies  are  in  various 
phases  of  developing  corporate  goals,  architectures,  information  systems,  and  implementa¬ 
tion  strategies.  They  are  making  decisions  regarding  the  selection  of  hardware  and  software 
vendors,  and  about  involving  suppliers  and  customers  in  their  integration  effort. 

Without  exception,  all  the  aerospace  companies  we  visited  started  their  enterprise 
integration  implementation  activities  by  expanding  their  integrated  CAD  activities  to 
broader  areas  within  the  company  and  to  a  greater  number  of  subcontractors,  key  suppliers, 
and  customers. 

As  in  the  electronics  sector,  aerospace  companies  are  initiating  enterprise  integra¬ 
tion  efforts  largely  because  they  feel  they  “have  no  choice.”  The  perception  within  the  aero¬ 
space  community  is  that  enterprise  integration  will  improve  their  competitiveness.  In 
addition,  contract  requirements  including  the  CALS  initiative  are  driving  them  toward 
improved  information  management  and  sharing. 

Teaming  arrangements  among  several  prime  aerospace  companies  for  large  Depart¬ 
ment  of  Defense  (DoD)  procurements  have  acted  to  accelerate  efforts  to  support  external 
exchange  of  product  data.  The  impact  of  this  and  the  resulting  enteiprise  integration  is  most 
evident  in  the  B-2  (Northrop,  Boeing,  and  Vought)  and  F-22  (Lockheed,  General  Dynam¬ 
ics,  and  Boeing)  development  and  production  programs. 

The  rationale  for  implementing  enteiprise  integration  within  each  of  the  companies 
we  visited  varied.  Fundamentally,  most  aerospace  companies  felt  that  enterprise  integration 
is  an  essential  element  in  ensuring  that  the  company  remained  competitive  and  in  business. 
From  this  reason  all  other  reasons  the  resulting  actions  flowed. 

Being  competitive  is  generally  associated  with  having  better  products  (quality),  at 
lower  cost  (price),  delivered  to  the  marketplace  in  a  timely  fashion  (schedule).  In  the  three 
industry  sectors  we  visited,  the  belief  is  that  better  quality  can  be  driven  by  integrating  the 
product  and  process  development. 
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Many  aerospace  companies  viewed  enterprise  integration  as  the  next  logical  step  in 
their  concurrent  engineering,  Total  Quality  Management  (TQM),  CALS  and/or  Product 
Definition  Exchange  Specification  (PDES)  activities. 

Frequently,  a  manufacturing  process  is  physically  separated  from  the  design  pro¬ 
cess.  Designers  and  developers  must  ensure  that  subsystems  interface  properly.  The  effec¬ 
tiveness  of  integrated  product  development  (IPD)  teams  is  greatly  facilitated  by  an 
integrated  development  environment  populated  with  tools  and  providing  the  appropriate 
services. 

A  requirement  for  achieving  an  effective  IPD  team  was  the  timely  transference  of 
product  and  process  data.  This  led  to  significant  interest  in  modeling  both  the  product  and 
the  process.  The  greatest  technical  concern  for  implementing  information  infrastructures  to 
the  companies  we  visited  is  product  data  representation. 

In  a  number  of  cases,  the  ability  to  remain  competitive  was  expressed  by  the  need 
to  reduce  the  product  development  cycle  time.  This  resulted  in  the  additional  emphasis  on 
concurrent  engineering  techniques  such  as  expanded  product  development  teams  with 
more  extensive  involvement  of  subcontractors  and  suppliers. 

Each  company  acknowledged  the  requirement  or  desire  to  have  a  method  that 
would  allow  them  to  measure  the  progress  brought  about  by  implementing  components  of 
an  enterprise  integration  plan.  This  is  understandable  since  the  cost  estimates  to  fully  imple¬ 
ment  enterprise  integration  provided  to  the  study  team  were  in  the  tens  of  millions  of  dol¬ 
lars.  However,  in  some  cases,  the  ability  to  identify  meaningful  metrics  was  difficult.  Part 
of  that  difficulty  was  staff  resistance.  Fear  that  the  metrics  would  be  interpreted  as  a  mea¬ 
sure  of  their  own  performance  discouraged  full  participation  by  many  employees.  Often  the 
net  cost  benefits  or  savings  cited  were  expressed  as  the  result  of  avoiding  costs  through 
more  effective  ways  of  doing  business. 

The  single  most  frequently  identified  barrier  to  the  implementation  of  enterprise 
integration  was  the  cultural  change  required  by  the  employees.  This  finding  parallels  that 
in  the  electronics  and  automotive  industry  sectors.  All  employees  of  the  company,  includ¬ 
ing  top  management,  will  possibly  be  required  to  change  how  they  deal  with  one  another. 
Corporate  changes  may  also  be  required  in  most  cases.  Policies  and  practices  will  need  to 
be  rewritten.  In  enterprise  integration  systems  there  are  open  availability  and  wide 
exchange  of  meaningful  data  which  results  in  more  widely  recognizable  and  known  perfor¬ 
mance  of  all  the  individuals  and  their  corresponding  organizational  elements. 


The  single  most  frequently  identified  technical  barrier,  particularly  when  the  enter¬ 
prise  expanded  beyond  the  primary  company,  was  the  large  number  of  different  and  not  eas¬ 
ily  integrated  engineering,  business  information,  and  two-dimensional  and  three- 
dimensional  design  hardware  and  software  systems  which  are  being  utilized  and  sold.  Inter¬ 
nal  and  external  integration  problems  have  been  compounded  by  different  standards,  hard¬ 
ware  requirements,  and  software  interfaces.  Yet  in  all  cases  where  a  consistent  set  of 
standards  was  identified,  the  companies  did  not  feel  that  there  were  any  major  technical 
impediments  to  implementing  enterprise  integration. 

D.1,2  BUSINESS  STRATEGIES 

Both  the  military  and  commercial  aerospace  companies  are  being  strongly  afrected 
by  contracting  markets  and  increased  competition.  The  business  strategies  being  formulat¬ 
ed  at  these  companies  reflects  this. 

>^th  a  declining  defense  budget  and  a  reduced  number  of  DoD  procurements,  aero¬ 
space  companies  are  increasing  their  emphasis  on  identifying  core  competencies  and  rely¬ 
ing  on  partnerships  to  improve  their  overall  competitive  position  on  DoD  procurements, 
and  to  share  costs  and  risks. 

In  the  commercial  aerospace  sector,  continued  pressures  from  foreign  competition, 
and  the  perception  that  U.S.  aerospace  firms  are  not  competing  on  a  level  playing  field  due 
to  foreign  subsidies,  have  driven  the  formulation  of  new  business  strategies  and  a  call  for 
changes  in  government  regulations. 

A  declining  airline  market  and  a  move  within  this  market  to  purchase  and  reuse  old¬ 
er  or  unused  equipment  has  resulted  in  reductions  (and  in  some  cases  losses)  in  corporate 
profits.  This  has  also  resulted  in  smaller  internal  research  and  development  (IR&D)  pro¬ 
grams,  bid  and  proposal  (B&P)  budgets,  and  R&D  contracts.  This  combination  has  forced 
most  companies  to  reassess  their  business  positions  and  strategies. 

Generally,  across  the  aerospace  industry  we  found  some  common  themes  among 
companies.  Aerospace  companies  are  reassessing  their  position  within  their  market  area 
(defense  or  commercial)  and  identifying  new  corporate  goals.  Pratt  and  Whitney  found  that 
its  customers  were  dissatisfied  with  their  product  support,  and  that  Pratt  and  Whitney  was 
not  meeting  its  goals  of  being  a  “world  class  supplier.”  This  goal  was  reaffirmed  and  spe¬ 
cific  programs  were  initiated  to  track  and  resolve  customer  problems  expeditiously.  These 
programs  are  based  on  deploying  enterprise  integration  across  all  divisions  of  the  company. 


D-6 


As  part  of  their  effort  to  reassess  their  market  position,  most  of  the  companies  we 
visited  have  begun  planning  and  implementing  programs  to  enhance  the  total  quality  of 
their  processes  as  the  primary  way  of  achieving  their  stated  goals  and  objectives.  These  pro¬ 
grams  generally  involve  improved  management  and  sharing  of  information  which  is  the 
foundation  of  enterprise  integration. 

At  GE,  the  first  step  was  to  get  a  concurrent  engineering  program  in  place  as  quickly 
as  possible.  This  program,  which  will  include  both  manufacturing  and  engineering,  is 
expected  to  be  fully  deployed  by  1995.  Lockheed  has  a  corporate- wide  TQM  program  to 
decrease  costs  and  schedules,  while  increasing  quality  and  enabling  continuous  process 
improvement.  Northrop  sought  to  decrease  the  number  of  people  required  to  support  the 
business  and  save  money. 

The  programs  within  the  companies  bore  a  strong  similarity  to  each  other.  They 
only  differed  in  two  areas:  the  progress  that  had  been  made,  and  the  underlying  driver  for 
the  program.  Lockheed,  GE,  and  Northrop  were  strongly  driven  by  contract  and  govern¬ 
ment  requirements  while  other  companies  tended  to  be  driven  by  competitive  market  fac¬ 
tors. 

The  factors  affecting  the  implementation  of  the  enterprise  integration  programs  are 
both  cultural  and  contractual.  Cultural  factors  include  the  speed  with  which  corporate  cul¬ 
tural  change  could  take  place,  and  new  company  policies  and  practices  could  be  written  and 
imposed.  Contractual  factors  include  issues  like  allowing  sufficient  contract  flexibility  to 
permit  a  company  to  implement  new  processes  for  cost  savings,  and  the  availability  of 
funding  to  implement  needed  projects. 

The  companies  we  visited  were  working  with  their  key  subcontractors  and  suppliers 
to  strengthen  their  relationships  in  a  strategy  to  increase  the  sharing  of  risks.  In  most  com¬ 
panies  this  strategy  included  reducing  the  number  of  suppliers.  In  one  company  the  trend 
to  reduce  the  number  of  suppliers  has  been  reversed  recently. 

Most  of  the  aerospace  companies  recognized  the  need  for  both  inter-  and  intra¬ 
enterprise  integration.  Currently,  inter-enterprise  integration  remains  a  problem  for  very 
small  companies  who  lack  the  infrastructure  investments  required  to  support  it.  Integration 
of  activities  and  collaborative  work  are  seen  by  many,  to  be  of  fundamental  importance. 

Finally,  the  companies  we  visited  were  making  an  effort  to  identify  the  core  tech¬ 
nologies  that  the  company  would  retain,  and  in  which  areas  investments  would  be  made  so 


as  to  assure  itself  a  place  in  future  markets.  These  efforts  frequently  included  an  involve¬ 
ment  in  selected  standards  committees. 

At  all  the  aerospace  companies  we  visited,  top  management  defined  the  corporate 
goals  and  objectives  and  became  personally  involved  in  implementing  programs  to  achieve 
them.  Expanding  upon  the  earlier  successes  of  their  concurrent  engineering  or  TQM 
efforts,  each  begun  to  establish  IPD  teams  within  all  the  organizational  elements  and  func¬ 
tional  processes  involved  with  the  design,  production,  operation,  and  support  of  their  prod¬ 
ucts.  In  all  cases,  reducing  the  time  involved  in  the  total  process  was  a  key  element  in 
achieving  established  elements  goals,  and  this,  in  turn,  was  tied  to  the  need  and  ability  to 
transfer  data  quickly  and  accurately,  which  lead  to  the  requirement  for  inter-  and  intra-com¬ 
pany  integrated  enterprise  system. 

D.l  J  STATE  OF  INTEGRATION 

In  this  section  we  describe  the  state  of  enterprise  integration  in  the  aerospace  indus¬ 
try.  The  information  which  forms  the  basis  for  this  overview  was  collected  during  our  visits 
to  the  aerospace  companies  in  1991  and  again  in  1993. 

Of  particular  interest  and  note  was  the  progress  and  the  changes  we  observed 
between  the  first  and  second  visits.  The  aerospace  industry  is  under  stress  due  to  the  finan¬ 
cial  pressures  of  a  shrinking  marketplace,  declining  orders,  and  increased  competition  from 
foreign  sources.  Given  this  economic  climate,  the  response  of  the  aerospace  companies  has 
been  telling.  In  each  case,  the  company  has  maintained  its  commitment  to  enterprise  inte¬ 
gration.  Although  projects  to  deploy  enterprise  integration  require  an  initial,  sometimes 
substantial  investment,  the  aerospace  companies  we  spoke  to  all  felt  that  the  benefits  justi¬ 
fied  the  effort.  In  many  cases  we  did  observe  a  reassessment  of  priorities,  a  lengthening  of 
deployment  schedules,  or  a  minor  modification  of  the  plans.  But  between  the  first  and  sec¬ 
ond  visits  we  saw  significant  forward  progress  in  most  cases. 

Every  aerospace  company  we  visited  has  an  enterprise  integration  effort  underway. 
These  efforts  varied  widely  in  both  the  approach  that  was  being  taken  and  the  progress  that 
had  been  made  by  the  time  of  our  last  visit 

Enterprise  integration  efforts  often  begin  within  an  organization  by  automating 
selected  functions  of  the  business,  creating  islands  of  automation.  The  next  step  is  often  to 
begin  to  connect  these  islands  of  automation,  creating  continents  of  automation.  This  pro¬ 
cess  may  continue  until  the  entire  company  is  fully  integrated.  These  intra-enterprise  inte- 


gration  efforts  may  result  in  benefits  such  as  cost  and  schedule  savings,  and  improved 
quality. 

While  substantial  benefits  may  result  from  intra-enterprise  integration,  additional 
benefits  can  result  from  efforts  to  integrate  operations  with  subcontractors,  suppliers,  and 
customers.  This  inter-enterprise  integration  is  more  difficult  to  achieve,  and  requires  a  com¬ 
pany  to  assess  and  understand  its  existing  business  and  engineering  processes.  These  pro¬ 
cesses  include  both  those  exclusively  inside  a  company  and  those  involving  outside 
players,  such  as  customers,  suppliers,  and  subcontractors.  By  understanding  all  these  pro¬ 
cesses,  progress  can  be  made  in  streamlining  and  improving  those  processes,  and  then  final¬ 
ly  automating  them.  There  is  unanimous  agreement  among  the  aerospace  companies  that 
automating  business  and  engineering  processes  before  fully  understanding  them  is  danger¬ 
ous. 

Several  of  the  aerospace  companies  we  visited  have  made  significant  efforts  to 
understand  and  improve  their  processes  through  process  modeling.  Lockheed  applied  the 
2^chman  framework  to  develop  its  Computer  Integrated  Systems,  Technologies,  and 
Resources  (CISTAR)  architecture.  This  architecture  will  bring  together  previously  disjoint 
processes  into  a  seamless  integrated  product  development  and  support  system. 

By  analyzing  its  business  processes,  Pratt  and  Whitney  discovered  that  its  product 
support  service  needs  were  not  being  met  largely  due  to  its  approach  to  data  management. 
The  Vision  2000  program  has  produced  a  data  management  architecture  that  will  tie  togeth¬ 
er  the  business  and  technical  processes  required  to  support  Pratt  and  Whitney  products.  The 
same  architecture  will  lead  to  cost  savings,  shorter  development  times,  and  better  quality 
products. 

After  identifying,  analyzing  and  possibly  refining  its  business  processes,  a  company 
may  begin  to  integrate  the  activities  associated  with  these  processes.  Integration  of  activi¬ 
ties  implies  an  exchange  and  sharing  of  the  information  used  and  generated  by  the  activi¬ 
ties.  An  infrastructure  for  communication,  data  management,  and  data  manipulation  is 
needed  for  this  exchange  and  sharing  of  information. 

The  aerospace  companies  we  visited  were  using  various  tools  and  technologies  to 
provide  this  infrastructure.  Electronic  mail  is  a  minimum  requirement  and  is  often  the  first 
step  taken  in  an  enterprise  integration  effort 

Data  management  is  an  area  where  significant  work  has  been  done.  GE  has  devel¬ 
oped  ADSRS  (Automated  Drawing  Storage  and  Retrieval  System),  an  electronic  storage 


and  retrieval  system,  as  one  component  of  its  inft'astructure.  This  system  has  substantially 
reduced  the  time  it  takes  to  check  out,  modify,  and  check  back  in  a  drawing. 

Pratt  and  Whitney  has  developed  an  enterprise  integration  data  management  system 
to  support  its  IPD  process.  This  system  supports  every  phase  of  the  business  process, 
including  supplying  engineering  tools,  managing  the  information,  coordinating  the  process 
activities,  and  managing  the  process. 

The  Integrated  Weapons  Systems  Database  (IWSDB)  developed  by  Lx)ckheed  and 
Advanced  Research  Projects  Agency  (ARPA)  manages  both  technical  and  management 
data.  This  system  provides  the  sponsor  access  to  schedule,  logistics,  and  technical  data. 
This  system  will  allow  most  contract  data  requirements  lists  (CDRLs)  to  be  delivered  elec¬ 
tronically. 

The  aerospace  industry  may  be  characterized  as  a  collection  of  companies  coming 
together  to  form  fluid,  temporary  alliances  for  the  purposes  of  bidding  on  or  satisfying  a 
procurement  request  With  this  type  of  arrangement  communication  becomes  critical. 
Some  of  the  factors  driving  the  requirements  for  team  communication  include  the  follow¬ 
ing: 

•  The  physical  separation  of  the  team  members 

•  The  size  of  the  team 

•  The  type  of  the  data  to  be  shared  among  team  members 

•  The  volume  of  data  to  be  transmitted 

•  The  time  constraints  on  data  transmission 

•  Security  concerns 

The  need  to  transmit  large  amounts  of  data  over  great  distances  in  a  timely  fashion, 
or  to  permit  geographically  separated  design-team  members  to  simultaneously  work  on  the 
same  design,  has  been  underscored  by  the  teaming  of  aerospace  conrpanies  on  recent  major 
DoD  weapon  system  procurement  programs.  Most  notable  examples  of  teaming  have  been 
the  B-2  procurement  (Northrop,  Boeing,  and  Vought)  and  the  F-22  development  program 
(Lockheed,  Genial  Dynamics,  and  Boeing). 

Pratt  and  Whitney  has  established  a  hierarchy  of  teams  as  part  of  its  IPD  Process. 
The  hierarchy  includes  an  Integrated  Product  Management  Team  (IPMT)  for  each  of  its 
major  products.  Under  each  IPMT  is  a  coll«:tion  of  Component  Integrated  Product  Teams 
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(CIPT).  Reporting  to  each  CIPT  is  a  group  of  Integrated  Product  Teams  (IPT).  This  team 
hierarchy  includes  members  from  all  functional  and  operational  groups. 

GE  has  established  an  IPD  Management  Team  for  all  its  products.  These  teams 
include  members  from  design,  production,  purchasing,  product  engineering,  logistics,  and 
the  customer. 

A  critical  need  for  a  team  is  to  be  able  to  exchange  information.  For  the  exchange 
of  business  data,  EDI,  provides  the  capability  needed  to  support  the  business.  This  is  a  com¬ 
monly  accepted  and  widely  used  standard.  EDI  is  typically  used  between  suppliers  or  cus¬ 
tomers  and  the  aerospace  company. 

The  exchange  of  technical  data  (product  data)  is  more  difficult  Non-standard 
exchange  formats  often  prevent  efficient  sharing  of  information.  The  technical  aspects  of 
all  enterprise  integration  programs  investigated  started  by  expanding  upon  the  electronic 
data  exchange  of  the  two-dimensional  and  three-dimensional  CAD  systems  and  their  relat¬ 
ed  computer-aided  engineering  (CAE)  and  computer-aided  manufacturing  (CAM)  systems. 

Electronic  data  exchange  has  shortened  problem  resolution  and  program  decision 
times  and  has  enhanced  the  involvement  and  commitment  of  many  DoD  organizations. 

The  following  were  key  technical  drivers  for  enterprise  integration  within  the  B-2, 
F-22,  and  other  programs: 

•  Ensuring  that  during  design  phase,  product  components  and  subsystems  would 
work  together  properly  (that  is,  the  ability  to  generate  electronic  3-D  mock-ups 
to  model  interfaces  and  motion  occurring  as  parts  are  assembled  or  operated). 

•  Designing  the  product  and  developing  the  manufacture/assembly  processes 
simultaneously  with  input  from  each  aspect  influencing  the  other. 

•  Involving  subcontractors  and  suppliers  as  early  as  possible  in  the  product  design 
and  development  process. 

•  The  early  exchange  of  product  design  data  with  tool  designers. 

•  Exchanging  of  CDRLs  and  data  requirements  lists. 

The  improved  effectiveness  of  all  organizations  using  three-dimensional  CAD  elec¬ 
tronic  information  data  exchange  systems  was  expressed  in  terms  of  cost  avoidance,  time 
savings,  product  development  team  understanding,  and  project  decision  making.  These 
improvements  have  been  documented  by  each  of  the  companies  visited.  Northrop  and  its 


B-2  teammates,  Boeing  and  Vought,  were  able  to  rapidly  prototype,  with  minimal  rework, 
many  of  the  B-2  components  because  of  the  accuracy,  resolution,  and  interference  checking 
attributes  of  the  Northrop  CAD  (NCAD)  system  which  all  parties  used.  Several  senior  aero¬ 
space  managers  felt  that  it  was  totally  reasonable  to  look  forward  to  being  able  to  handle 
all  prototyping  electronically  and  to  eliminate  the  cost  of  full  scale  mock-ups.  The  B-2,  LH, 
767  (RB-211  engine  strut  design),  and  the  777  programs  have  all  used  forms  of  electronic 
mock-ups. 

Strategic  sourcing,  as  described  in  Appendix  B.  1.3.8,  is  also  an  important  strategy 
in  the  aerospace  industry.  Some  companies,  for  example,  Pratt  and  Whitney,  have  begun  a 
concerted  effort  to  reduce  their  supplier  base.  Pratt  and  Whitney  has  expressed  a  desire  to 
move  toward  a  single  supplier  for  some  items.  In  doing  so,  it  hopes  to  develop  a  shared  risk 
arrangement  with  the  supplier.  Other  companies,  like  GE,  have  adopted  a  different  strategy. 
They  had  begun  to  reduce  their  supplier  base  with  the  goal  of  moving  toward  a  single  sup¬ 
plier.  During  a  recent  downturn  in  business,  they  found  that  they  needed  to  hold  prices  to 
retain  market  share.  Their  supplier  however  continued  to  raise  prices.  This  prompted  a  deci¬ 
sion  to  maintain  at  least  two  suppliers  for  all  items. 

Like  the  electronics  and  automotive  industries,  CAD/CAM  tool  selection  has  a 
major  impact  on  the  enterprise  integration  effort  within  the  aerospace  industry. 

Enterprise  integration  is  seen  by  many  companies  as  the  next  step  in  the  implemen¬ 
tation  of  concurrent  engineering  or  TQM,  or  as  an  extension  of  the  CALS  and  PDES  pro¬ 
grams.  The  aerospace  industry  has  a  unique  requirement  based  on  the  long  life  of  its 
products,  and  the  overriding  concern  with  safety.  The  requirement  that  the  data  associated 
with  their  products  be  available  at  all  times  implies  an  evolutionary  move  to  enterprise  inte¬ 
gration.  While  integrating  or  replacing  legacy  information  systems,  the  data  must  remain 
available  and  usable.  Due  to  this  requirement  some  technologies,  for  example,  object-ori¬ 
ented  databases  for  the  management  of  design  data,  are  viewed  as  being  too  leading  edge 
and  not  yet  proven. 

One  definition  of  a  legacy  system  is  a  system  where  the  data  is  embedded  within  the 
application  that  uses  it.  Thus,  a  new  application  designed  to  be  intertwined  with  the  data  it 
operates  on  immediately  becomes  a  legacy  system.  Like  the  electronics  and  automotive 
industries,  companies  in  the  aerospace  industry  have  a  significant  number  of  large  legacy 
systems  to  deal  with  during  an  integration  effort 
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There  are  three  options  for  a  company  with  legacy  system.  A  company  may  retain 
the  existing  legacy  system.  This  may  be  done  for  legal  or  safety  reasons  in  the  aerospace 
industry.  It  may  also  be  done  for  cost  reasons. 

A  company  may  choose  to  re-engineer  legacy  systems.  Lockheed  has  elected  to  re¬ 
engineer  some  of  its  existing  systems.  At  Pratt  and  Whitney,  the  entire  data  management 
system  was  redesigned  to  support  the  IPD  process  after  that  process  was  defined.  During 
this  change,  the  75  to  80  existing  change  management  systems  were  forced  to  tie  into  a 
common  system,  forcing  a  phase-out  of  many  of  the  local  change  management  systems. 

GE  replaced  the  legacy  drawing  storage  and  retrieval  system  based  on  microfilm 
records  with  digitized  drawings  in  the  ADSRS  system.  This  change  has  resulted  in  a  50% 
reduction  in  the  time  required  to  make  drawing  changes  and  a  savings  of  $5  million  to  $8 
million  per  year. 

A  third  option  for  companies  is  to  encapsulate  or  integrate  existing  systems.  Lock¬ 
heed  has  done  this  with  its  automated  shop  floor  scheduler.  This  system  integrates  several 
older  systems  previously  used  to  perform  manual  scheduling.  The  IWSDB  also  includes 
several  older  systems  that  were  not  re-engineered  but  rather  encapsulated  and  provided 
with  interfaces  to  the  new  system. 

D.13.1  Success  Stories 

Integration  within  an  enterprise  (intra-enterprise  integration)  includes  integration 
across  functional  and  operational  areas  such  as  engineering,  manufacturing,  testing,  logis¬ 
tics  and  support,  and  program  management.  Intra-enterprise  integration  results  in  cost  and 
time  savings  due  to  increased  process  efficiency. 

Inter-enterprise  integration,  integration  among  contractor  teams  including  subcon¬ 
tractors,  suppliers  and  customers,  further  increases  the  potential  cost  and  time  savings. 

Key  to  any  enterprise  integration  effort  is  extending  the  range  of  data  that  may  be 
exchanged  and  shared  across  the  enterprise.  Examples  of  the  type  of  data  that  are  currently 
being  exchanged  include  three-dimensional  CAD  model  data,  product  description  data, 
EDI  data,  and  program  management  data. 

In  this  section  we  describe  some  of  the  results  of  inter-  and  intra-enterprise  integra¬ 
tion  reported  from  the  aerospace  industry.  Where  possible,  specific  metrics  are  given  to 
illustrate  the  magnitude  of  the  savings  possible. 
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•  A  decrease  from  an  average  of  S  changes  in  printed  circuit  board  (PCB)  draw¬ 
ings  during  the  pre-ECAD  design  process  to  an  average  of  2.2  changes  per 
drawing  with  ECAD.  This  amounted  to  an  annual  savings  of  over  $168  million 
(2.8  fewer  changes  made  to  12,000  drawings  in  1990,  at  a  cost  of  $5,000  per 
change).  The  goal  is  to  further  reduce  this  number  to  1.9  changes  per  drawing. 

•  The  number  of  iterative  design  cycles  needed  to  produce  a  printed  circuit  board 
(PCB)  was  reduced  from  2.5  to  1.5. 

•  The  number  of  engineering  man-hours  to  prepare  a  mock-up  of  a  complete  sys¬ 
tem  was  reduced  from  2,100  hours  to  900  hours  by  moving  from  a  physical  to 
an  electronic  mock-up. 

•  Using  the  old  system  of  developing  physical  mock-ups  resulted  in  a  131% 
increase  in  materials  and  labor  during  design,  development,  and  fabrication. 
Using  electronic  mock-up  and  pre-assembly,  there  was  virtually  no  rework,  no 
scrap,  and  the  components  could  be  assembled  the  first  time  viith  no  interfer¬ 
ence.  Although  the  mock-up  process  incurred  an  up-front  schedule  slip,  there 
was  no  redesign  required  and  no  time  was  lost  during  manufacture.  The  result 
was  project  completion  ahead  of  schedule. 

•  Using  three-dimensional  modeling  decreased  the  cycle  time  from  design  initia¬ 
tion  to  release  to  manufacturing  by  ^%. 

•  The  use  of  stereo  lithography  for  preliminary  modeling  of  mechanical  parts 
from  plastic  has  helped  engineering  and  management  visualize  the  product 
much  more  economically  than  when  wooden  or  metallic  mock-ups  were  fabri¬ 
cated. 

•  A  gross  measurement  of  the  improvement  in  effectiveness  of  a  division’s  inte¬ 
gration  efforts  and  process  improvements  was  an  increase  in  total  sales  from  a 
smaller  work  force,  i.e.,  from  $750  million  annual  sales  with  15,000  employees 
in  1979  to  $2.5  billion  sales  with  8,600  employees  in  1990. 

•  A  9.4%  reduction  in  engineering  hours,  a  34%  reduction  in  weight,  and  a  43% 
reduction  in  shop  floor  real  estate  occurred  during  design  and  production  of  a 
major  aircraft  assembly. 

•  A  significant  reduction  in  error  rate  occurred  for  the  first-time  bending  of 
hydraulic  lines  and  fabricating  electrical  wiring  harnesses.  The  original  error 
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rate  using  conventional  paper  drawings  was  95%,  then  was  reduced  to  50%  with 
the  use  of  two-dimensional  CAD  systems,  and  further  reduced  to  5%  through 
use  of  an  integrated  three-dimensional  CAD  system. 

•  A  $5  million  savings  resulted  when,  by  using  an  integrated  three-dimensional 
CAD  system,  a  specification  change  was  made  on  a  large  number  of  drawings. 

•  Ten  percent  of  an  engineer’s  time  was  typically  wasted  due  to  poor  configura¬ 
tion  management  and  the  use  of  outdated  or  poorly  integrated  databases.  An 
integrated  data  management  system  with  appropriate  configuration  controls  can 
eliminate  this. 

•  The  utilization  of  a  CALS-like  graphics  text  editor  system  allowed  a  company 
proposing  on  two  program  areas  to  show  considerable  cost  savings  when  com¬ 
pared  to  previous  methods  of  doing  the  work.  These  tasks  were  conducting  the 
needed  Logistic  Support  Analyses,  a  $10  million  savings,  and  production  of 
technical  orders,  a  $20  million  savings.  This  computer-based  system  also 
reduced  costs  to  produce  reports  meeting  Airlines  Transport  Association  and 
Federal  Aviation  Administration  (FAA)  specifications. 

•  One  company  estimates  that  40%  of  processing  and  25%  of  labor  costs  are 
attributable  to  data  translation.  Twenty-four  million  dollars  in  savings  was  real¬ 
ized  by  re-designing  and  integrating  data  management  functions  across  all  its 
business  processes. 

•  An  on-line  electronic  drawing  storage  and  retrieval  system  decreased  the  time 
required  to  make  engineering  changes  by  50%,  and  produced  savings  of 
between  $5  million  and  $8  million  per  year.  This  system  also  decreased  the 
number  of  people  required  to  provide  that  service. 

•  Nearly  all  first-made  special,  high  performance  mechanical  and  avionics  parts 
had  such  a  good  fit  due  to  using  three-dimensional  CAD  electronic  mock-ups 
that  two  companies  expect  to  eliminate  the  need  for  producing  future  physical 
mock-ups. 

•  A  company  has  modified  its  contract  to  include  electronic  delivery  of  CDRLs 
to  the  SPO  (subsystem  project  office)  and  several  supporting  DoD  organiza¬ 
tions.  It  found  that  the  electronic  interchange  of  data  led  to  a  much  closer 
involvement  of  all  parties  in  the  development  of  the  product  and  the  consequent 
avoidance  of  numerous  problems  that  would  have  surfaced  later  in  the  develop- 
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ment,  production,  and  support  cycle.  This  resulted  in  significant  cost  avoidance 
savings.  One  measure  of  the  improvement  was  a  reduction  from  6  months  for 
approved  release  of  provisioning  lists  to  60  minutes. 

•  Electronic  distribution  and  review  of  data  decreased  the  attendance  at  formal 
design  reviews  by  50%,  saving  $72,000  per  review  meeting. 

•  Use  of  the  Contractor  Integrated  Techitical  Information  Service  (CITIS)  was 
projected  to  decrease  the  need  for  informal  technical  interchange  meetings,  sav¬ 
ing  around  $3.5  million  over  the  rennaining  contract  period. 

•  Product  problem  resolution  decreased  firom  100  days  (from  entry  into  the  sys¬ 
tem  to  closeout)  to  less  than  20  days. 

•  Providing  customers  with  electronic  access  to  a  problem  resolution  database 
and  the  system  account  of  a  single  responsible  engineer  increased  customer  con¬ 
fidence  and  satisfaction. 

•  Using  an  integrated  data  management  system  the  cost  of  exchanging  problem 
reports,  engineering  change  orders,  and  configuration  control  data  among 
world- wide  partners  dropped  from  $1.5  million  per  year  to  $120,0(X)  per  year. 

•  Providing  critical  infrastructure  con^nents,  such  as  hardware  and  software 
site  licenses,  to  sub-tier  partners  too  small  to  make  the  financial  investments  in 
an  infrastructure,  enabled  inter-enterprise  integration  with  those  partners. 

•  Data  management  costs  decreased  by  moving  from  a  mainframe  to  a  distributed 
system. 

D.1.4  INTEGRATION  STRATEGIES 

In  this  section  we  will  discuss  integration  strategies  identified  by  die  aerospace 
companies  during  this  study.  Individual  strategies  differ  in  significance  between  the  com¬ 
mercial  and  military  aerospace  companies.  Where  these  strategies  differ  or  coincide  with 
those  employed  in  the  electronics  and  automotive  sectors,  we  will  provide  a  rationale. 

D.1.4.1  Architect  the  Int^rated  Enterprise 

As  described  in  B.  1.4.1,  integrating  an  enterprise  involves  understanding  the  exist¬ 
ing  business  and  engineering  processes,  streamlining  and  improving  those  processes,  and 
then  finally  automating  them.  It  also  involves  managing  the  data  associated  with  those  pro- 
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cesses  in  a  way  that  supports  appropriate  exchange  and  sharing.  This  approach  applies 
equally  well  to  the  electronics,  automotive,  and  aerospace  industries. 

The  characteristics  of  the  aerospace  industry  that  influence  the  strategy  of  integrat¬ 
ing  the  enterprise  include  the  extended,  complex  nature  of  the  team  structure,  the  involve¬ 
ment  of  a  DoD  sponsor,  and  the  safety  concerns  and  long-lived  product  life  cycle. 

•  The  teaming  structure  associated  with  most  aerospace  products  requires  that  the 
enterprise  architect  consider  duplicated  processes  across  the  team  members,  dif¬ 
fering  company  policies  and  practices,  and  the  use  of  different  standards. 

•  The  presence  of  a  DoD  sponsor  may  require  the  implementation  of  specific  pro¬ 
cesses  to  fulfill  government  contract  requirements.  Opportunities  for  electronic 
CDRL  and  other  data  delivery,  and  electronic  sign-off  should  be  pursued. 

•  The  long  life  and  safety  concerns  for  aerospace  products  may  require  certain 
legacy  systems  and  development  and  test  tools  to  be  maintained  for  the  life  of 
the  product  despite  the  new  integrated  enterprise  infrastructure. 

D.1.4.2  Enable  Team  Communication 

The  same  requirements  for  peer-to-peer  communication  that  exist  for  the  electron¬ 
ics  sector  as  described  in  Appendix  B.  1.4.3  also  apply  in  the  aerospace  industry.  The  only 
difference  is  that  the  teams  in  the  aerospace  industry  tend  to  be  larger  and  consist  of  many 
more  companies  than  in  the  electronics  industry.  This  makes  the  need  for  effective  commu¬ 
nication  even  critical. 

D.  1.4.3  Support  Both  Intra-  and  Inter-Enterprise  Integration 

Enterprise  integration  efforts  generally  begin  within  an  organization  by  automating 
and  integrating  selected  functions  of  the  business.  Substantial  benefits  may  result  from 
these  efforts.  These  benefits  may  include  cost  and  schedule  savings,  and  improved  quality. 
A  company  can  then  use  these  benefits  as  an  incentive  to  continue  its  integration  efforts  fur¬ 
ther.  Recognizing  the  benefits  derived  from  its  intra-integration  efforts,  a  company  may 
extrapolate  these  benefits  for  the  scenario  when  they  are  integrated  with  customers,  suppli¬ 
ers,  and  subcontractors.  While  substantial  benefits  may  result  from  intra-enterprise  integra¬ 
tion,  additional  benefits  can  result  from  efforts  to  inter-enterprise  integration.  This  inter¬ 
enterprise  integration  is  more  difficult  to  achieve,  due  to  the  involvement  of  separate  com¬ 
panies  with  differing  corporate  cultures,  policies,  and  procedures,  standards  and  tools  in 
use,  and  financial  constraints. 
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D.1.4.4  Establish  Strategic  Sourcing 

Strategic  sourcing,  as  described  in  Appendix  B.  1.3.8,  is  also  an  important  strategy 
in  the  aerospace  industry.  By  establishing  strategic  partnerships,  aerospace  companies  can 
share  the  risks  and  costs  associated  with  developing  large,  complex  expensive  products. 
Long-term  alliances  allow  the  companies  to  establish  quality  standards,  and  help  each  other 
achieve  them.  These  partnerships  may  also  be  required  to  ensure  that  critical  components 
remain  available  as  needed  over  the  product  life  cycle. 

D.1.4.5  Select  Common  CAD/CAM  Tools 

Like  the  electronics  and  automotive  industries,  CAD/CAM  tool  selection  has  a 
major  impact  on  the  enterprise  integration  effort  within  the  aerospace  industry.  Aerospace 
sector  teams  generally  involve  a  larger  number  of  companies.  This  makes  the  requirement 
to  adhere  to  a  selected  set  of  tools  or  standards  even  more  critical. 

D.  1.4.6  Evolve  Predictably  to  Enterprise  Integration 

Aerospace  companies  must  identify  their  need  for  maintaining  certain  product  data 
for  either  safety  or  contractual  requirements.  This  information  is  then  used  during  the  enter¬ 
prise  architecture  design  phase  before  enterprise  integration  is  begun. 

Companies  may  begin  by  automating  and  integrating  areas  where  the  largest  payoff 
is  expected  to  result.  This  way  the  benefits  of  enterprise  integration  may  be  seen  immedi¬ 
ately.  Enterprise  integration  may  then  be  expanded  into  other  areas  and  to  suppliers,  cus¬ 
tomers,  and  subcontractors. 

It  is  critical  that  the  business  processes  are  not  disrupted  during  integration,  and  that 
the  critical  data  remains  available  both  during  and  after  the  integration  effort. 

D.1.4.7  Replace  Legacy  Systems 

Like  the  electronics  and  automotive  industries,  companies  in  the  aerospace  industry 
have  a  significant  number  of  large  legacy  systems  to  deal  with  during  an  integration  effort 
A  decision  must  be  made  based  on  what  to  do  with  these  legacy  systems,  based  on  cost/ 
benefit  studies,  and  safety  or  contractual  concerns.  Integration,  encapsulation,  interfacing 
or  bridging,  and  re-design  are  all  options  that  may  be  appropriate  in  different  instances. 

D.  1.4.8  Other  Strategies 

Many  of  the  integration  strategies  discussed  in  the  electronics  section  apply  to  the 
aerospace  industry  as  well.  These  include  establishing  customer  advisory  councils  as  a 
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mechanism  to  include  customers  in  the  IPD  team,  and  exploring  the  use  of  state-of-the-an 
tools  and  services  like  object  management  systems. 

D.1.5  INFORMATION  INFRASTRUCTURE 

The  components  of  an  information  infrastructure  are  largely  the  same  for  the  elec¬ 
tronic,  automotive,  and  aerospace  sectors.  Thus,  the  discussion  in  Appendix  B.1.5  applies 
equally  as  well  here.  However,  the  aerospace  industry  is  structured  slightly  differently  and 
is  driven  by  some  unique  characteristics  not  shared  by  the  electronics  sector. 

In  this  section  we  describe  the  components  of  an  information  infrastructure  and  how 
they  are  used  to  support  the  integration  of  enterprises  in  the  aerospace  industry.  Both  the 
software  and  hardware  components  of  the  infrastructure  will  be  discussed. 

In  both  infra-  and  inter-enterprise  integration  the  companies  composing  the  enter¬ 
prise  or  team  are  connected  by  a  computer  network.  A  network  provides  the  only  efficient 
mechanism  for  information  exchange  and  sharing.  The  ability  of  a  network  to  provide  flex¬ 
ibility  and  dynamic  configuration  is  what  enables  the  fluid  structure  of  the  enterprise.  Com¬ 
panies  or  divisions  are  able  to  form  and  dissolve  partnerships  dynamically  without  any 
physical  or  outward  changes.  Team  members  can  remain  remotely  located  during  the  part¬ 
nership.  Physical  location  of  a  team  member  has  virtually  no  impact  on  the  access  to  or  use 
of  project  information. 

In  the  aerospace  industry,  enterprises  typically  involve  a  large  number  of  members 
representing  many  companies.  This  is  because  aerospace  products  are  complex  and  involve 
many  components.  Each  enterprise  member  company  contributes  in  a  narrow  technical 
area.  The  network  is  able  to  bring  the  large  number  of  players  together  seamlessly,  obscur¬ 
ing  company  boundaries. 

The  complex  nature  of  an  aerospace  product  results  in  large  amounts  of  sometimes 
complex  data  being  generated  throughout  the  life  cycle  of  that  product  Three-dimensional 
CAD  modeling  may  be  required  during  several  phases  of  the  development  process,  includ¬ 
ing  design  and  analysis,  pre-assembly,  testing,  and  maintenance  analysis.  Networks  must 
provide  high-speed,  high-bandwidth  communication  of  this  data  among  the  appropriate 
team  members. 

Data  management  systems  are  used  by  the  enterprise  to  organize  and  control  the 
data  generated  by  the  team  members.  A  data  management  system  may  provide  services 
such  as  configuration  control  and  management,  notification,  check-in  and  check-out,  and 


D-I9 


audit  trails.  A  data  management  system  may  provide  a  common  data  model  for  the  enter¬ 
prise  to  ease  the  complexity  of  information  exchange  among  the  companies. 

In  the  aerospace  industry,  the  size  of  the  enterprises  formed  to  develop  products,  as 
well  as  the  safety  concerns  regarding  those  products,  requires  that  a  sophisticated  data  man¬ 
agement  system  be  used  to  support  the  enterprise. 

A  data  management  system  will  potentially  manage  one  or  more  legacy  databases. 
The  options  for  these  legacy  systems  include  re-engineering,  integrating  or  encapsulating, 
or  simply  retaining  them.  A  small  number  of  CAD  tools  use  object  bases  for  the  storage  of 
design  data. 

Another  component  of  the  infrastructure  to  support  an  integrated  enterprise  is  an 
integrated  development  system.  This  system  supports  an  IPD  team  by  providing  a  multi¬ 
function  tool  environment.  The  system  allows  tool  registration  and  access.  It  can  be  used 
to  enforce  certain  standards.  It  can  also  be  used  to  control  the  development  process  by  auto¬ 
mating  policies  and  business  practices. 

The  hardware  to  support  an  aerospat^  industry  integrated  enterprise  is  often  a  het¬ 
erogenous  platform  mix.  The  trend  is  away  from  main  frames  toward  a  client-server  archi¬ 
tecture  with  the  storage  of  very  large  design  files  on  servers.  Fairly  powerful  workstations 
are  often  required  to  run  some  of  the  CAD  tools  used  in  the  aerospace  industry.  CAD  tool 
licenses  are  expensive.  As  a  result,  these  tools  are  often  installed  on  a  few  workstations  so 
that  a  smaller  number  of  seat  licenses  can  be  purchased  to  save  money.  These  CAD  tools 
typically  provide  an  extension  language  used  by  members  of  the  team  to  add  specific  capa¬ 
bilities  to  the  tool. 

In  the  aerospace  sector  both  hardware  and  software  costs  still  limit  the  ability  of 
low-level  tier  subcontractors  and  suppliers  to  become  integrated  with  the  enterprise.  Small¬ 
er  companies  do  not  have  the  financial  ability  to  invest  in  the  necessary  infrastructure  com¬ 
ponents. 

Another  member  of  die  enterprise,  the  DoD  sponsor,  is  also  often  not  integrated 
with  the  rest  of  the  team.  Lack  of  hardware  and  software  prevent  the  sponsor  from  partici¬ 
pating  in  the  electronic  partnership.  Typically,  DoD  contracts  often  do  not  allow  the  con¬ 
tractor  to  provide  these  infrastructure  components  for  the  sponsor. 
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D.1.6  LESSONS  LEARNED 


The  aerospace  companies  interviewed  during  our  site  visits  have  significant  enter¬ 
prise  integration  efforts  underway  and  were  able  to  report  observations  and  findings  from 
their  work  to  date.  Many  of  the  experiences  reported  to  us  by  the  companies  are  similar 
across  the  industry,  and,  in  fact,  across  the  three  industry  sectors  included  in  this  study.  In 
this  section  we  will  describe  some  of  the  lessons  learned  in  the  aerospace  industry  regard¬ 
ing  its  enterprise  integration  efforts.  We  will  describe  similarities  or  differences  between 
the  aerospace  industry  and  the  other  industry  sectors  where  necessary. 

D,L6.1  Cultural  Change 

As  in  the  electronics  and  automotive  industries,  cultural  changes  remain  the  single 
hardest  problem  encountered  during  enterprise  integration.  All  the  aerospace  companies 
visited  agreed  that  the  biggest  barrier  to  overcome  during  enterprise  integration  is  not  the 
“hard”  or  technical  issues,  but  the  “soft”  or  cultural  and  management  issues. 

One  approach  to  effect  a  cultural  change  is  to  champion  the  changes  from  the  top- 
down  by  getting  corporate  involvement,  and  implement  the  changes  from  the  bottom-up  by 
getting  employee  buy-in. 

In  some  cases,  a  new  management  approach  is  required.  Management  tends  to 
oppose  radical  changes  involving  itself.  One  company  found  that  replacing  or  retraining 
management,  and  moving  new  people  in  to  deploy  enterprise  integration  was  a  successful 
approach. 

D.1.6.2  Legacy  Systems 

The  data  associated  with  aerospace  industry  products  must  be  retained  for  safety 
and  legal  reasons  far  longer  than  data  in  either  the  electronics  or  automotive  industries. 
Thus,  the  data  in  the  aerospace  industry  is  extremely  stable  even  while  the  industry  under¬ 
goes  continual  change  associated  with  mergers  and  teaming  arrangements.  This  data  must 
be  retained  at  any  cost.  Recognizing  this  constraint,  legacy  systems  are  considered  less  of 
a  problem  in  the  aerospace  industry  than  in  other  industry  sectors. 

D.L6.3  Paradigm  Shift  in  Data  Management 

A  conclusion  by  many  of  the  companies  we  visited  is  that  data  must  be  managed 
where  and  when  it  is  produced.  In  the  past,  data  associated  with  a  product  was  managed  by 
a  system  that  was  built  to  reflect  the  organization  of  the  company.  That  is,  the  organization 
of  the  company  was  driving  its  business  processes.  Companies  are  continually  reorganiz- 


ing.  Despite  this,  data  tends  to  remain  relatively  stable.  This  then  results  in  redundancies 
and  inconsistencies  in  the  data.  One  company  realized  that  they  had  been  employing  a 
smokestack  mentality  with  regard  to  its  data  management,  and  found  it  necessary  to  move 
toward  a  more  horizontal  data  flow  and  management,  ^^^thout  an  integrated  data  manage¬ 
ment  system,  data  is  recreated  unnecessarily  across  the  enterprise. 

Teaming  arrangements  bring  partners  in  contact  with  proprietary  information. 
Companies  can  be  partners  one  day  and  competitors  the  next  Legal  issues  and  security 
mechanisms  must  be  handled  carefully. 

D.1.6.4  Justifying  Enterprise  Int^ration 

In  some  cases  aerospace  companies  have  participated  in  competitive  benchmarking 
efforts  to  evaluate  their  business.  Often  the  results  of  this  benchmarking  are  used  to  justify 
plans  and  funding  for  an  enterprise  integration  program  within  one  or  more  of  the  partici¬ 
pating  companies. 

Some  companies  collect  metrics  internally,  evaluate  their  business,  and  project  the 
enhanced  market  position  based  on  an  enterprise  integration  effort.  In  at  least  one  case,  cor¬ 
porate  management  had  difficulty  accepting  this  cost  justification,  but  decided  that  it  need¬ 
ed  the  program  anyway. 

Some  companies  have  been  able  to  justify  an  enterprise  integration  program  on  the 
sheer  common  sense  of  it. 

D.1.6,5  Automation 

Technology  should  only  be  brought  to  bear  where  it  makes  sense,  rather  than  for  the 
sake  of  the  technology  itself.  Automating  a  poor  process  does  not  fix  the  process.  The  pro¬ 
cess  should  be  re-engineered  before  any  thought  is  given  to  whether  to  automate  it  or  not. 
The  two  are  independent  of  each  other. 

D.1.6.6  Teaming 

Fluid  teaming  arrangements  spread  tiie  risk  and  capitol  investment  associated  with 
a  large  project.  In  the  aerospace  industry,  projects  are  much  larger,  more  costly,  and  higher 
risk  than  in  either  the  electronics  or  automotive  industries.  Teaming  arrangements  are  a 
necessity.  Enterprise  integration  vastly  improves  the  functioning  of  a  team. 
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In  the  aerospace  industry,  teams  consist  of  both  very  large  and  very  small  players. 
The  smaller  players  often  find  it  difficult  or  financially  impossible  to  conform  to  standards 
or  practices  established  within  the  enterprise  by  the  larger  players. 

D.1.6.7  Standards 

Throughout  the  aerospace  industry  we  found  concern  for  the  standards  being  devel¬ 
oped  to  support  the  industry.  Standards  for  product  and  process  description  are  developing 
too  slowly.  Many  companies  have  elected  not  to  wait  for  a  single  standard  to  emerge  or  to 
be  blessed  formally.  Their  businesses  cannot  afford  to  wait.  Instead,  they  are  using  what 
exists.  In  this  way  several  de  facto  standards  seem  to  be  emerging. 

CAD  standards  are  necessary  if  engineers  are  to  exchange  and  share  geometry  data. 
STEP  (Standard  for  Transfer  and  Exchange  of  ft-oduct  Data)  is  beginning  to  address  some 
industry  concerns  in  this  area. 

Many  of  the  aerospace  companies  we  visited  feel  that  too  many  standards  are  being 
proposed  and  developed.  Some  of  these  are  overlapping,  others  inconsistent  Aerospace 
companies  are  facing  difficult  economic  times  and  cannot  afford  to  track  and  support  all  of 
these  standards.  The  result  is  that  they  are  being  more  selective  in  the  standards  they  sup¬ 
port. 


D.1.6.8  Technology 

Technology  was  not  considered  by  any  of  the  aerospace  companies  we  visited  to  be 
constraint  for  enterprise  integration.  The  aerospace  companies  we  visited  believe  that  the 
technology  to  support  enterprise  integration  exists  today. 

The  cost  of  deploying  that  technology  at  the  lower-level  tiers  in  the  enterprise  is  still 
prohibitively  high  in  some  cases.  This  essentially  makes  that  technology  unavailable  to 
those  team  members,  and  thus  limits  their  participation  in  enterprise  integration. 

D.2  AEROSPACE  INDUSTRY  2001 

In  this  section  we  describe  the  state  of  the  aerospace  industry  in  2001.  The  four 
characteristics,  technology,  competition,  teaming,  and  long-lived  systems  and  safety  con¬ 
cerns,  used  to  describe  the  aerospace  industry  in  1993,  will  be  used  in  this  discussion. 

Technology  continues  to  drive  the  industry.  Composites  and  other  materials 
research  advances  have  changed  the  way  aircraft  and  their  component  parts  are  designed 


and  manufactured.  Digital  mock  up  and  stereolithography  are  used  to  the  exclusion  of  tra¬ 
ditional  model  shops  and  full-scale  mock-ups. 

Advances  in  the  technologies  supporting  enterprise  integration,  such  as  network 
access,  product  data  models  and  exchange  formats,  and  other  technologies  such  as  object 
bases,  and  CAD,  CAM,  and  CASE  tools,  have  meant  a  heavier  reliance  on  electronic  inter¬ 
actions  supporting  a  more  decentralized  business  with  dispersed  partners  and  players.  A 
leaner  marketplace  requires  a  careful  investment  in  these  infrastructure  technologies.  How¬ 
ever,  the  benefits  of  these  investments  are  evident:  saving  time,  money,  and  allowing  con¬ 
current  engineering,  leading  to  higher  quality  products  and  a  more  competitive  company. 

By  2001,  the  number  of  companies  in  the  aerospace  business  have  been  significant¬ 
ly  reduced.  This  reduction  mirrors  the  shrinking  traditional  market  However,  government 
'  rgulations  which  previously  hampered  sales  to  foreign  markets  have  been  eased  some¬ 
what  However,  competition  with  foreign  aerospace  companies  receiving  subsidies  contin¬ 
ues  to  be  a  concern  to  the  domestic  aerospace  industry. 

Teaming  continues  to  be  the  norm  in  the  aerospace  industry  in  2001.  Some  former 
team  members  are  no  longer  in  business  however.  In  some  cases  this  was  due  to  mergers. 
New  types  of  partnerships  have  been  possible,  including  arrangements  with  government 
agencies,  foreign  governments,  and  new  foreign  investors. 

The  nature  of  the  new  structure  has  taken  many  different  forms,  the  least  radical 
being  (1)  the  merger  of  several  companies  resulting  in  a  fewer  prime  and  subcontractors, 
(2)  considerable  cross-teaming  to  ciq)italize  on  scarce  and  distributed  technical  capabilities, 
and  (3)  some  multi-national  teaming.  This  structure  is  responding  to  a  more  intelligent  DoD 
whose  needs  are  for  even  more  diverse  weapons  that  are  far  more  cost  effective  and  can  be 
readily  moved  and  efficient  in  a  wide  range  of  conflicts. 

Long-lived  systems  and  safety  are  still  concerns  in  the  aerospace  industry.  New 
information  systems  have  improved  the  tracability  of  all  data  associated  with  a  product, 
however. 

D,2.1  THE  VISION 

Even  with  the  future  structure  not  well  defined,  there  is  general  consensus  on  the 
process  through  which  enterprise  integration  has  been  implemented  and  the  results  of  that 
implementation. 
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Companies  have  fully  implemented  the  concepts  of  just-in-time  (JIT),  concurrent 
engineering,  TQM,  CALS,  and  PDES.  IPD  teams  are  used  throughout  the  organizations  to 
ensure  the  best  available  talent  address  particular  design  and  process  problems  and  they 
interface  in  the  most  cost-effective  manner.  Interactions  among  potentially  geographically 
dispersed  team  members  are  supported  by  electronic  networks. 

There  is  a  common  implementation  of  open  systems  and  distributed  computer 
architectures  throughout  each  company.  Since  many  elements  of  a  company  are  widely  dis¬ 
persed,  networks  capable  of  carrying  large  amounts  of  text  and  graphics  have  been  installed 
and  are  operational.  All  organizational  elements,  including  research,  engineering  develop¬ 
ment,  production,  logistic/support,  administration,  finance,  human  resources,  and  other 
groups,  have  appropriate  access  to  the  same  set  of  object  bases.  This  interconnection  per¬ 
mits  all  elements  to  have  their  information  integrated.  To  reach  this  capability  the  associat¬ 
ed  interface  standards  have  been  established  to  permit  effective  access  to  the  system  with  a 
wide  variety  of  hardware  and  software.  This  tu^cess  has  been  coupled  with  the  recognition 
that  each  organizational  element  has  made  large  investments  in  computers  and  associated 
equipment  (the  legacy  system).  By  having  an  open  architecture,  the  company  has  eased 
many  interfacing  problems. 

With  the  increased  need  to  team  with  competitors  to  effectively  respond  to  Requests 
for  Proposals  (RFPs),  an  Internet  capability  has  been  established  to  tie  nearly  all  of  the 
prime  contractors,  major  subcontractors,  and  appropriate  DoD  offices,  including  the  SPOs 
and  Air  Logistics  Centers  (ALCs).  Similar  to  the  internal  information  system  described 
above,  there  is  an  acceptable  security  system  which  will  limit  access  to  proprietary  infor¬ 
mation.  Although  text  and  graphical  information  is  of  great  proprietary  importance,  the  key 
concern  is  still  the  exchange  of  critical  process  information  which  may  or  may  not  be  in  that 
format 

Mth  a  system  of  networks  established,  the  effectiveness  of  the  manufacturing  floor 
has  been  tremendous  improved  with  advent  of  paperless  or  less  paper  fabrication  and 
assembly.  With  relative  small  assembly  rates  needed  for  most  DoD  systems,  considerable 
organizational  and  assembly  consolidation  has  taken  place  so  more  cost-effective  produc¬ 
tion  of  diverse  items  occurs.  Surge  capabilities  will  exist  in  limited  places. 

With  effective  three-dimensional  CAD,  including  animation  to  ensure  proper  fit  and 
operation  among  multiple  parts,  and  CAM  systems  tied  directly  to  part  fabrication 
machines,  the  “old”  model  shops  will  have  long  ago  been  absorbed  within  production,  i.e.. 
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the  fabrication  of  parts  for  a  new  prototype  system  will  be  manufactured  along  with  existing 
production  items  through  truly  flexible  manufacturing  centers. 

D.2^  FUTURE  INFORMATION  INFRASTRUCTURES 

Nearly  all  of  the  technology  required  to  support  an  integrated  enterprise  is  available 
in  1993.  Between  1993  and  2001  most  of  the  changes  we  anticipate  are  in  the  use  of  this 
existing  technology. 

As  described  in  the  section  on  Future  Information  Infrastructures  for  the  electronics 
industry.  Appendix  B.2.2,  the  enabling  technologies  for  information  infrastructures  include 
distributed  computing  and  Open  System  Interconnection  (OSI)  networks,  and  object-ori¬ 
ented  management  and  tool  services.  The  technologies  required  in  the  electronics  industry 
are  the  same  as  those  required  in  the  aerospace  industry. 

Computer  networks  will  expand,  providing  greater  coverage  and  higher-speed 
access  to  all  parts  of  nation  and  globe.  This  will  allow  greater  connectivity  among  compa¬ 
nies  interested  in  participating  in  enterprises.  Companies  providing  network  access  and  ser¬ 
vices  will  become  more  competitive  in  the  types  of  services  provided  as  well  as  the  cost  of 
these  services.  This  will  allow  snudler  companies  or  individuals  to  join  electronic  partner¬ 
ships. 

Data  management  systems  will  include  more  object-oriented  databases  in  addition 
to  the  legacy  relational  databases  that  currently  exist  and  will  continue  to  be  developed. 

Integrated  development  environimnts  will  mature  as  vendors  begin  to  market 
‘^framework”  products.  These  frameworks  may  be  designed  as  frameworks  of  frameworks 
if  standards  fail  to  emerge.  The  development  of  these  systems  will  be  facilitated  by  matur¬ 
ing  standards  in  the  area  of  open  systems,  object  management,  CAD  and  other  tool  inter¬ 
faces,  and  data  exchange  formats.  Integrated  development  environments  will  provide 
increasing  support  for  collaborative  work  through  the  concepts  associated  with  groupware. 

Computer  hardware  will  continue  to  evolve.  The  move  away  from  mainframe  com¬ 
puters  will  continue  in  the  aerospace  industry.  Standards  will  increase  the  interoperability 
among  the  heterogenous  mix  of  workstations  and  servers  configured  across  the  enterprise. 

D J  ISSUES  AND  BARRIERS 

The  most  significant  inhibitor  to  the  implementation  of  enterprise  integration  in  the 
aerospace  industry  is  the  requirement  for  changes  in  culture  within  die  various  companies. 
This  finding  was  unanimous  among  the  companies  we  visited,  and  was  cited  during  both 
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the  1991  and  1993  visits.  This  finding  was  also  echoed  in  the  electronics  and  automotive 
industries. 

The  critical  cultural  changes  identified  by  the  aerospace  companies  we  visited  cen¬ 
tered  on  several  issues.  One  issue  is  that  of  information  exchange  and  sharing.  The  type  of 
information,  including  the  amount  of  detail,  that  must  be  exchanged  among  various  parts 
within  an  organization  and  with  outside  subcontractors,  suppliers,  and  customers,  is  an  area 
of  disagreement.  This  issue  reflects  the  openness  a  company  is  prepared  to  establish  regard¬ 
ing  its  data.  Company  data  is  a  valuable  asset.  A  balance  between  protecting  this  asset  and 
enabling  a  more  efficient  business  process  must  be  established. 

Teaming,  or  establishing  partnerships  with  other  aerospace  vendors,  is  widely  rec¬ 
ognized  by  members  of  the  aerospace  industry  as  vital  to  their  success  in  competing  for 
major  contracts.  However,  although  practiced  for  many  years  already,  teaming  continues  to 
be  an  area  of  concern  in  the  industry.  The  concern  centers  on  the  use  of  technologies  and 
practices  to  support  an  integrated  enterprise  approach,  and  the  sharing  of  information  and 
practices  with  companies  that  were  previously  competitors. 

Progress  measurements  and  the  visibility  these  provide  represent  another  cultural 
issue  creating  barriers  to  enterprise  integration.  The  “old”  ways  of  doing  business  were 
comfortable  and  unless  there  were  significant  reasons  such  as  financial,  there  was  reluc¬ 
tance  to  accept  the  changes. 

To  implement  the  needed  culture  changes,  the  companies  we  visited  identified  var¬ 
ious  strategies  and  approaches.  The  first  was  the  commitment  and  direct  involvement  of  the 
top  executives  in  establishing  new  business  goals  and  objectives  and  the  processes  by 
which  these  were  to  be  attained.  Using  teams  from  all  areas  of  the  company,  corresponding 
changes  in  policies,  procedures,  and  organizations  were  identified  through  modeling  and 
analyses  of  the  work  activities  and  processes. 

Training  to  improve  the  needed  personnel  skills  was  identified,  scheduled,  and 
implemented. 

Metrics  were  found  to  measure  the  improvements  within  all  effected  areas;  these 
areas  included  engineering,  management,  and  support  staff  as  well  as  manufacturing. 

Leadership  from  all  levels  of  the  organization  was  needed  to  initiate  such  action  as 
team  building,  instilling  trust  among  all  segments  of  the  organization,  encouraging  open 
self-appraisal,  and  instituting  continuous  quality  improvement. 
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One  of  the  biggest  problems  is  standards:  too  manv  standards  exist  or  are  being 
developed  for  any  single  company  to  track  and  support  These  standards  are  often  conflict¬ 
ing  and  extremely  slow  to  evolve.  Generally,  aerospace  companies  And  that  they  cannot 
wait  for  a  standard  to  be  developed  or  officially  released.  Instead  they  must  proceed  with 
whatever  is  available  to  help  them  get  their  job  done. 

The  issue  of  proliferation  or  lack  of  standards  arises  when  information  sharing  or 
exchange  must  occur  within  or  between  aerospace  companies.  As  noted  earlier,  the  tenden¬ 
cy  is  to  grow  enterprise  integration  from  a  company’s  CAD  system.  Unfortunately,  not  all 
aerospace  firms  (including  their  subcontractors  and  suppliers)  use  the  same  CAD  system. 
Some  use  commercially  available  products,  others  use  in-house  developed  CAD  systems. 

Even  where  the  CAD  system  may  be  the  same,  application  software  such  as  analysis 
tools  may  be  different.  Versions  of  the  same  CAD  system  may  not  be  directly  compatible. 

CATIA  was  found  in  this  study  to  be  the  system  in  widest  use;  the  second  most  used 
was  Unigraphics.  In  most  cases  the  Initial  Graphics  Exchange  Specification  (IGES)  was 
used  as  the  exchange  format 

This  study  also  found  that  most  CAD  application  software  is  developed  by  each 
aerospace  company  to  suit  its  own  unique  design  needs  and  approaches.  In  most  cases, 
design  application  software  is  considered  proprietary  and  can  only  be  exploited  when  used 
with  a  company’s  design  data  bases. 

Another  major  hinderance  was  legacy  systems  such  as  computers,  communications, 
and  management  controls.  These  were  found  to  be  not  readily  changeable  due  to  high  cost 
time,  or  technical  constraints.  Common  ways  around  such  barriers  were  development  of 
bridges  between  the  legacy  systems  (interfaces),  building  around  them,  maintaining  them 
but  initiating  new  systems  for  the  future,  and  maintaining  maximum  flexibility  within  prod¬ 
uct  and  process  design  and  implementation. 

Proprietary  information  is  a  major  concern  among  aerospace  companies  who  may 
be  currently  teamed  with  a  future  competitor.  Security  mechanisms  and  procedures  will 
need  to  be  developed  and  proven  before  many  companies  feel  comfortable  with  inter-enter¬ 
prise  integration. 

The  size  of  most  aerospace  companies,  as  well  as  the  complexity  and  cost  of  their 
products,  requires  that  any  effort  to  integrate  the  enterprise  be  done  in  a  phased  approach. 
It  is  not  possible  to  integrate  thousands  of  workers  overnight 
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The  size  of  many  subcontractors  and  suppliers  prohibits  the  substantial  investments 
in  an  infrastructure  necessary  to  support  enterprise  integration.  These  companies  are  often 
unable  to  invest  in  equipment  and  software  licenses  to  enable  participation  in  electronic 
data  exchange  with  the  prime  and  first-tier  aerospace  contractors. 

D.4  RECOMMENDATIONS 

Companies  indicated  there  were  several  constraints  which  could  be  eased  by  chang¬ 
es  in  DoD  policy,  regulations,  and/or  procedures. 

With  the  significant  increase  in  the  development  and  exchange  of  electronic  design 
and  maintenance  information,  corresponding  changes  need  to  occur  in  how  the  DoD 
requires  receipt,  review,  and  storage  of  that  data.  Specifically,  Federal  Acquisition  Regula¬ 
tions  (FARs)  should  be  changed  so  they  no  longer  limit  the  ability  of  the  SPOs  and  other 
units  to  procure  needed  computer  equipment  to  send  and  receive  the  data.  One  option  is  for 
the  contractors  to  place  terminals  within  a  DoD  office  using  contract  funds.  This  has  been 
demonstrated  on  the  F-22  project 

With  the  increased  complexity  of  most  weapon  systems,  it  has  become  almost 
impossible  to  fully  describe  parts  and  their  interconnections  on  normal  two-dimensional 
paper  representations.  Requirements  should  be  changed  to  permit  the  exchange  of  data 
among  the  procuring  and  developing  organizations.  A  key  aspect  is  that  the  DoD  needs  to 
commonly  accept  receipt  of  design  and  design  interface  data  electronically. 

Control  of  data  firom  a  normal  DoD  security  aspect  has  required  separate  data  lines 
to  be  installed  and  maintained.  That  poses  considerable  added  cost  to  the  teaming  organi¬ 
zations.  With  the  addition  of  special  access  requirements  in  addition  to  the  normal  DoD 
classifications  of  confidential,  secret  and  top  secret,  there  are  further  limits  to  effective 
information  exchange. 

)^th  the  potential  for  large  cost  savings  being  attained  by  using  enterprise  integra¬ 
tion  systems,  corresponding  changes  are  needed  within  various  cost-benefit  models  used  by 
DoD  organizations  to  evaluate  and  assess  companies'  proposals  and  development  efforts. 
Such  updates  need  to  include  revised  ways  in  which  data  is  being  exchanged  and  used. 

The  Environmental  Protection  Agency  (EPA)  and  Occupational  Safety  and  Health 
Administration  (OSHA)  requirements  of  identifying  and  tracking  hazardous  material  are 
placing  an  increased  burden  on  the  aviation  industry  and  aircraft  operators  and  owners.  Var¬ 
ious  forms  of  aluminium  or  pieces  of  scrap  have  been  determined  to  be  hazardous;  the  addi- 
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tional  costs  to  track  each  appropriate  sized  part,  although  quite  large  for  the  aircraft 
manufacturer,  will  be  even  greater  for  the  Services.  Proper  systems  to  handle  this  informa¬ 
tion  need  to  be  acquired  soon. 

Since  most  aircraft  companies  produce  products  for  both  domestic  and  foreign  air¬ 
lines  as  well  as  for  the  DoD,  there  is  room  for  improved  efficiency  if  the  DoD,  FAA,  Airline 
Transportation  Association,  and  foreign  regulating  organizations  were  able  to  minimize 
their  unique  data  requirements. 

DJ  LH  T  OF  COMPANIES  VISITED 


Digital  Equipment  Cor¬ 
poration 

•  Enterprise  Integration 
Technology  (EIT) 

•  Hughes  Aircraft  Corpo¬ 
ration 

International  Business 
Machines  Corporation 
(IBM) 

•  Intel  Corporation 

•  Motorola  Cellular  Sub¬ 
scriber  Group 

Motorola  Corporate 

•  Motorola  Paging  Prod¬ 
ucts  Group 

•  National  Semiconductor 

NeXT  Computers 

*  Tektronix,  Inc. 

•  Texas  Instruments 

Westinghouse  Electron¬ 
ic  Systems  Group 

•  Allison  Gas  Turbine, 
Division  of  GM 

•  CDI/Modem  Engineer¬ 
ing 

The  Cross  Company 

•  Ford  Motor  Company  of 
North  America 

•  General  Motors,  Chief 
Information  Officer 

Ryobi  Die  Casting 
(USA),  Inc. 

•  SATURN 

•  University  of  Michigan: 
Director/Office  for  the 
Study  of  Automotive 
Transportation  (OSAT) 

General  Electric  Aircraft 
Engines 

•  Lockheed  Aeronautical 
Systems  Con^any 
(LASC) 

•  Martin  Marietta  Missile 
Systems 

Northrop  Corporation 

•  United  Technologies - 
Pratt  and  Whitney 

# 
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DIGITAL  EQUIPMENT  CORPORATION  (DEC) 


Description  of  the  Business: 

Designer  and  manufacturer  of  computer  platforms  and  operating  system,  network¬ 
ing,  and  application  software. 

Industry  1991: 

Business  Strategy: 

DEC’S  approach  to  enterprise  integration  has  been  motivated  primarily  by  Time-to- 
Market  (TTM)  and  economic  concerns.  However,  DEC  does  not  make  most  integration 
decisions  based  on  formal  cost-benefit  analyses.  Rather  DEC  will  estimate  the  savings  after 
the  fact  They  tend  to  plan  and  implement  changes  to  decrease  time-to-market  (TTM), 
increase  competitiveness,  or  because  there  was  no  other  way  to  do  it. 

State  of  Integration: 

DEC  initiated  a  project  three  years  ago  to  make  product  development  information 
a  shared  resource  throughout  the  corporation.  A  major  component  of  the  project,  which 
builds  on  the  existing  D-Bus  Architecture,  is  the  BRIDGE  system. 

Engineering  product  data  and  metadata  were  the  initial  focus  of  this  integration 
effort  However,  as  the  system  concept  evolved,  it  grew  to  include  engineering  processes, 
and  further,  to  include  manufacturing. 

The  BRIDGE  system  was  designed  with  internal  engineers  and  manufacturing 
groups  reviewing  the  requirements  and  goals  for  the  product  development  information 
management  system.  The  group  developed  a  data  model  for  the  information  the  system 
would  need  to  support  to  fulfill  the  goals.  The  model  contains  both  product  and  process- 
based  data.  The  system  addresses  a  hierarchy  of  objects  including  projects,  parts  (and  sub¬ 
parts),  products,  generic  file  (types),  file  (instances),  processes  (and  subprocesses),  and 
tools. 

The  BRIDGE  system  provides  various  services  to  different  classes  of  users  such  as 
tracing  a  history  of  transactions  on  data  objects,  configuration  management,  and  version 
control.  Due  to  the  constantly  evolving  product  designs,  configuration  management  and 
version  control  are  vital  services. 

BRIDGE  provides  several  different  user  interfaces  ranging  from  menus  to  com¬ 
mand  line  input.  Remote  access  is  provided  through  the  use  of  a  client-server  paradigm. 
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Files  may  be  held  locally  for  performance  reasons  or  stored  remotely  due  to  capacity  limi¬ 
tations.  The  BRIDGE  project  makes  use  of  existing  software  packages  developed  at  DEC. 
The  KEEP  system  is  an  object-oriented  database  providing  a  wide  range  of  data  manage¬ 
ment  services. 

The  BRIDGE  system  has  been  operational  at  a  major  DEC  division  for  the  last  14 
months,  providing  access  to  product  development  information  to  over  150  users  daily. 
Roughly  600  to  800  transactions  per  day  are  logged.  The  current  implementation  manages 
over  l.S  gigabytes  of  design  data  contained  in  roughly  6,000  files. 

Before  this  project  was  begun,  there  was  always  verbal/manual  coordination 
between  manufacturing  and  engineering.  Now  files  are  viewed  and  shared  in  both  domains. 
DEC  is  fighting  a  cultural  barrier,  however,  in  trying  to  get  manufacturing  not  to  physically 
remove  files.  Manufacturing  feels  the  need  to  have  a  tangible  set  of  drawings  and  other 
data.  Feedback  between  engineering  and  manufacturing  on  issues  of  manufacturability  and 
reliability  can  now  occur  on-line.  System-wide  notification  of  design  changes  is  provided 
via  BRIDGE.  This  notification  is  in  the  form  of  electronic  mail  (e-mail). 

The  next  phase  of  the  project  will  provide  the  same  functionality  but  use  new  tech¬ 
nology.  Specifically,  an  improved  data  model  will  be  integrated  with  the  Atherton  Software 
Backplane  approach,  and  greater  use  will  be  made  of  object-oriented  programming  and 
database  features  to  enhance  system  extensibility. 

DEC  is  not  yet  considering  adding  an  on-line  ordering  capability  to  the  system.  For 
this  next  phase,  management  vision  will  play  a  much  more  minor  role  and  they  will  have 
to  justify  the  cost  of  eliminating  the  legacy  system.  To  do  this,  they  will  model  the  process 
visually  and  highlight  bottlenecks. 

Service  centers  can  log  into  BRIDGE  for  diagnostic  information.  This  was  not  part 
of  the  original  plan,  but  once  the  information  was  there  people  made  use  of  it.  Service  man¬ 
uals  are  not  yet  on  BRIDGE.  There  is  still  a  concern  that  pre-release  information  will  be 
used  too  early  (prior  to  approval)  and  inappropriately.  One  application  of  BRIDGE  is  that 
the  drill  and  die  information  is  now  pulled  off  and  processed  into  machine  software  that  is 
then  loaded  back  on  to  BRIDGE. 

Before  BRIDGE  it  took  12  to  IS  coordinators  to  manage  the  data.  Even  more  coor¬ 
dination  was  required  for  the  DEC  9000  proj«:t.  With  the  new  system,  two  and  one  half 
data  coordinators  are  required. 
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As  evidence  of  the  savings  afforded  by  Bridge,  it  now  takes  2  hours  for  a  mask 
information  change  to  be  released  (20  minutes  best  case).  That  is,  after  a  design  originating 
in  engineering  in  Massachusetts  is  transferred  to  California  and  fabricated,  and  tested  to 
uncover  errors,  the  error  report  is  transferred  back  to  engineering  and  the  file  is  changed  in 
20  minutes.  This  process  used  to  take  a  minimum  of  21  days. 

The  enterprise  integration  and  EDI  (Electronic  Data  Interchange)  effort  attempted 
with  the  BRIDGE  system  was  undertaken  on  the  DEC  9000  project  to  improve  upon  the 
approach  that  had  been  used  for  the  DEC  8600  project.  The  results  have  been  outstanding, 
and  the  approach  will  now  be  spreading  it  to  other  projects. 

On  the  8600  project,  engineering,  manufacturing,  delivery  and  all  the  other  func¬ 
tional  entities  were  housed  in  a  single  building.  On  the  9000  project  the  team  was  nationally 
and  internationally  distributed.  They  are  now  building  on  the  success  of  the  9000  to  get  the 
DEC  6000  project  out. 

On  the  9000  DEC  saved  six  months  in  delivery  time.  On  the  9000  they  saved  three 
to  five  months  by  eliminating  paper.  They  saved  60  days  in  part  ordering  by  having  an  on¬ 
line  database. 

Another  integration  effort  at  DEC  is  the  integrated  part  and  document  system 
(IPDS).  This  project  involves  the  management  of  metadata  associated  with  the  parts  pro¬ 
cess.  The  old  system  was  called  DOCS.  It  tracked  document  numbers  and  parts. 

IPDS  is  an  object  locator.  It  is  being  accessed  20  hours  per  day,  6  days  per  week. 
There  are  450,000  unique  object  locations.  The  average  number  of  users  at  any  time  is  20. 
IPDS  has  1.2  million  records,  and  over  50  users.  IPDS  feeds  the  manufacturing  process, 
supports  the  release  process,  supports  technical  publications,  provides  international  access 
to  information,  and  provides  contact  information  (change  control,  rework,  etc.). 

ERICA,  another  part  of  the  integration  effort,  replaced  microfiche  distribution  and 
maintenance.  It  has  saved  $675,000  per  year.  This  figure  does  not  include  “tub”  mainte¬ 
nance.  It  provides  24-hour  turnaround  with  view  and  print  capabilities.  The  funding  for  this 
project  is  spread  across  projects. 

Integration  Strategies: 

DEC  had  to  get  second-level  managers  involved.  On  the  9000  project  they  had 
high-  and  low-level  managers  involved.  No  middle  managers  were  involved.  There  were 
pockets  of  resistance  that  tended  to  change  as  the  project  progressed. 


The  decisions  on  the  integration  effort  were  program  driven.  Both  bottom-up  (Pro¬ 
gram  Manager)  and  top-down  (Vice  President)  were  required.  In  the  end,  an  edict  from  the 
Vice  President  made  it  succeed.  Without  him  the  cultural  aspects  of  the  company  would 
have  caused  a  failure.  Instead  of  automating  existing  processes,  he  directed  a  reengineering 
of  the  processes.  They  had  to  plan  for  organizational  and  cultural  changes. 

Previously,  islands  of  automation  existed.  This  caused  major  problems  because 
people  were  using  out  of  date  information.  Integration  allowed  DEC  to  save  time  and  mon¬ 
ey  (decreased  its  information  inventory),  and  saved  people  (to  manage  the  information). 
Further  DEC  used  the  opportunity  to  get  its  documentation  on-line. 

Selling  the  new  system  to  management  has  meant  “glorifying”  all  the  things  it  could 
do  for  them.  To  sell  it  to  the  engineers,  however,  in  order  not  to  scare  them,  they  had  to  iden¬ 
tify  their  particular  problem  and  show  the  how  the  system  would  fix  it.  People  are  skeptical 
and  their  trust  must  be  gained.  The  strategy  was  to  solve  small  problems  first,  then  grow  the 
solution. 

Information  Infrastructures: 

Unigraphics  and  ComputerVision  (CV)  are  used  for  mechanical  CAD  (computer- 
aided  design). 

The  technology  that  has  been  the  hardest  for  DEC  is  the  database  technology.  They 
have  developed  an  internal  object-oriented  database  (KEEP).  DEC  is  monitoring  conuner- 
cial  database  products.  The  applications  on  top  of  the  database  have  not  been  all  that  hard. 

Issues  and  Barriers: 

Cultural  barriers  are  the  greatest  problem  foe  enterprise  integration.  The  technical 
barriers  are  always  temporary  and/or  short  lived. 

It  turned  out  that  system  availability  was  most  important  to  users.  Performance  was 
also  critical. 

On  the  9000  project  vendors  did  not  have  on-line  access  to  information.  There  were 
legal  issues  of  net  access.  They  used  a  trusted  intermediary  (an  IBM  personal  computer) 
between  DEC  and  their  subcontractor’s  Motorola. 
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E.2  ENTERPRISE  INTEGRATION  TECHNOLOGIES  (EIT) 

Description  of  the  Business: 

EIT  is  a  new  research  and  development  (R&D)  and  consulting  organization  aimed 
at  increasing  enterprise  productivity.  That  is,  increase  the  rate  at  which  a  manufacturing 
enterprise  can  develop  and  implement  changes  to  its  operation  to  meet  the  needs  of  quickly 
changing  markets.  EIT  is  approximately  one  year^  old,  with  revenues  of  $1.2  million. 

Industry  1991: 

Business  Strat^: 

Err  is  concentrating  on  bringing  applications  supporting  concurrent  engineering, 
integrated  manufacturing,  and  electronic  commerce  to  specific  industry  sectors  such  as 
semiconductor,  aerospace,  computer,  and  system  houses  using  an  integration  framework 
and  a  set  of  tools. 

Two  Small  Business  Innovative  Researches  (SBIRs)  have  been  proposed  by  EIT. 
The  first  is  a  feasibility  plan  to  move  the  Manufacturing  Knowledge  System  (MKS)  out  of 
the  university  into  practise.  The  second  is  a  conununication  framework  for  mechanical 
CAD,  using  hypertext  and  a  concept  of  “shared  notebooks.” 

State  of  Integration: 

The  focus  of  the  work  at  EIT  is  on  integration  frameworks  and  tools  to  facilitate 
information  sharing  and  coordinate  decision  making.  The  view  at  EIT  is  that  a  great  deal 
of  integration  work  is  going  on.  Each  effort  is  taking  a  slightly  different  vector,  however. 
For  instance,  many  efforts  are  centered  around  developing  a  computer-integrated  manufac¬ 
turing  (CIM)  architecture.  In  some  cases  these  efforts  are  undertaken  by  groups  better  suit¬ 
ed  to  provide  specific  services  rather  than  specify  the  entire  architecture 

The  Center  for  Integrated  Systems  (CIS)  at  Stanford  University  is  similar  to  the 
CIM-OSA  (Computer-Integrated  Manufacturing — Open  System  Architecture  (European)) 
effort  except  that  at  Stanford  the  result  has  been  the  development  of  a  real  prototype.  This 
prototype  focuses  only  on  a  single  semiconductor  process,  however.  The  prototype  is  used 
to  develop  a  model  of  a  real-world  factory  where  simulations  can  be  played  out.  In  this  way, 
the  prototype  represents  a  virtual  factory.  The  prototype  can  also  be  used  to  program  a  fac¬ 
tory  floor.  This  capability  has  been  demonstrated  using  a  10,000  ft.^  research  facility  at 
Stanford  University. 

‘  As  of  the  faU  of  1991. 
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Integration  Strategies: 

Researchers  at  CIS  are  looking  at  a  five-year  time  Aame  to  transfer  some  of  these 
concepts  to  private  industry. 

Information  Infrastructure: 

The  CIS  prototype  uses  existing  databases  of  information  relating  to  the  factory 
being  described,  and  several  separate  applications  (tools).  The  prototype  provides  interfac¬ 
es  for  the  attachment  of  tools,  an  internal  object-oriented  database,  and  notification  servic¬ 
es. 

Lessons  Learned: 

The  goal  of  any  enterprise  integration  effort  should  be  to  understand  the  business 
thoroughly  and  streamline  the  processes  before  attempting  to  automate  those  processes. 

The  use  of  simulation  lags  behind  simulation  technology  significantly. 
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HUGHES  AIRCRAFT  CORPORATION 


Description  of  the  Business: 

Designer  and  developer  of  commercial  and  military  avionics. 

Industry  1991: 

Business  Strategy: 

Hughes  Aircraft  Corporation  was  motivated  by  competition  and  economics  to  begin 
to  implement  enterprise  integration.  The  corporate  culture  of  operating  group  autonomy 
has  made  enterprise  integration  difhcult  For  example,  the  acquisition  strategy  associated 
with  the  integration  effort  has  sometimes  conflicted  with  the  autonomy  of  an  operating 
group's  acquisition  strategy. 

Hughes  has  strong  technology  steering  groups  and  is  working  to  establish  a  strong 
process  focus  as  well.  Investments  are  based  upon  business  strategies,  and  technology 
investments  must  support  these  strategies,  such  as  time-to-market,  concurrent  engineering, 
and  so  forth. 

Integration  Strategies: 

Implementation  of  the  Corporate  CAD/CAM  integration  program  is  six  months  old. 
The  program  was  first  proposed  in  a  1989  plan  motivated  oy  budgetary  concerns.  That  plan 
identified  that  Hughes  could  realize  significant  savings  by  standardizing  and  integrating  its 
CAD/CAM  systems.  Standardization  would  also  reduce  the  amount  of  heterogeneity  in 
their  current  CAD/CAM  environment 

Phase  1  of  the  Information  Systems  Study  Team  (ISST)  Strategic  Information  Sys¬ 
tem  Planning  (SISP)  effort  was  the  development  of  the  vision  for  enterprise  integration. 
During  this  phase  the  study  team  worked  Hughes  business  goals  and  objectives  into  an  inte¬ 
gration  strategy.  Phase  2  of  the  plan  includes  the  development  of  a  detailed  business  model 
and  an  assessment  of  that  model.  During  this  phase  changes  in  Hughes  business  processes 
will  be  implemented.  Phases  1  and  2  will  be  a  one-year  effort.  During  Phase  3  the  study 
team  will  identify  implementation  risks  and  options,  develop  a  migration  plan  from  existing 
systems,  and  develop  technology,  application,  and  organization  architectures.  This  three  to 
five  year  effort  incorporates  top-down  planning  and  bottom-up  design  of  the  solution.  The 
Information  Engineering  Workbench  (lEW)  tool  will  be  used  to  capture  information  during 
each  phase  of  the  effort  Enterprise  integration  will  be  a  cross-corporation  effort.  This  is 
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notable  as  it  is  very  different  from  the  way  things  are  normally  done  at  Hughes.  Typically, 
groups  within  Hughes  have  complete  project  independence. 

The  Space  and  Communications  Group  (S&CG)  at  Hughes  began  an  enterprise 
integration  effort  in  May  1990.  Before  that  they  had  three  unsuccessful  attempts  at  enter¬ 
prise  integration.  It  was  a  learning  experience.  Hughes  executives  were  taught  courses  on 
information  management  The  effort  was  motivated  by  business  information  needs  and 
driven  at  the  operating  division  managers  level.  The  support  and  full  time  commitment  to 
the  project  of  an  executive-level  champion  are  the  reason  it  has  succeeded. 

The  S&CG  enterprise  integration  plan  outlined  a  roadmap  for  proceeding  with 
implementation.  The  first  step  was  to  address  data  exchange  standards  and  electronic  mail. 
The  electronic  mail  systems  will  be  the  first  area  to  be  integrated,  followed  by  the  data  sys¬ 
tems.  In  the  first  one  to  three  years,  S&CG  hopes  to  decrease  time-to-market  by  30%  bv 
integrating  its  operations  with  both  customers  and  suppliers.  In  the  next  3  to  10  years,  they 
hope  to  decrease  time-to-market  by  50%  (from  the  original  baseline). 

The  company  Information  Systems  Architecture  GSA)  Team  laid  out  a  multi-phase 
project  for  enterprise  integration.  The  project  centered  around  the  development  of  a  process 
model.  They  have  an  Information  Systems  Executive  Council  (ISEC).  This  group  is  look¬ 
ing  at  an  integrated  information  system  to  exchange  data  across  the  seven  operating  groups 
at  Hughes.  The  ISEC  is  also  sponsoring  an  effort  to  integrate  existing  systems,  identify 
common  Hughes  business  processes,  and  meld  the  technology  aspects  of  IS  with  the  busi¬ 
ness  process  aspect  of  IS.  These  two  were  traditionally  separate  with  an  emphasis  on  tech¬ 
nology.  In  linking  IS  to  business  process  improvement  the  project  begins  by  identifying 
who  the  executive  level  process  owner  is.  Until  there  is  an  identified  process  owner,  there 
is  natural  ownership  of  the  business  information. 

The  project  is  using  CASE  tools  and  business  area  analysis  to  model  their  business 
processes.  They  are  developing  a  process  model  that  will  be  reviewed  by  the  executives  to 
ensure  a  high  level  buy-in,  and  will  be  validated  by  approximately  ISO  experts  from  across 
the  corporation.  The  model  does  not  include  group-  or  sector-specific  information. 

The  suggested  data  architecture  for  the  model  is  based  on  the  S&CG’s  60  data  class¬ 
es.  The  group  dropped  one  data  class,  added  three,  and  provided  descriptions  of  data  and 
processes  for  the  communications  sector.  It  developed  a  matrix  using  a  technique  called 
CRUD  (created,  read,  updated,  deleted)  for  the  data  classes  and  processes.  Now  it  believes 
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that  it  is  ready  to  do  a  roadmap  for  systems  integration  and  management  as  they  move 
toward  enterprise  integration  at  Hughes. 

The  Missile  Systems  Group  (MSG)  began  a  product  data  management  system 
project.  This  project  was  found  to  be  strategic  to  the  company  and  MSG  was  asked  to  form 
a  multi-group  activity.  The  Ground  Systems  Group  had  a  framework  initiative  looking  at 
engineering  workflow  management  and  a  CAD  framework.  These  two  efforts  were  com¬ 
bined  to  become  a  company-wide  CAD/CAM  Integration  Plan  (CCIP)  initiative.  This  ini¬ 
tiative  will  address  both  the  product  development  process  and  the  information  systems 
needed  to  support  it. 

The  S&CG  is  working  toward  a  heterogenous,  distributed,  client-server  model  as 
the  basis  for  its  enterprise  integration.  The  goal  is  for  everything  to  be  mediated  by  the  data. 
The  focus  is  on  three  big  payoffs;  engineering  data  management,  integrated  resource  man¬ 
agement,  and  integrated  cost  and  schedule,  although  they  are  still  investigating  activity- 
based  costing.  S&CG  clearly  wants  integration  back  at  the  data  source,  but  that  would  take 
five  to  six  years.  So  it  is  focusing  on  quick  payoffs. 

S&CG  bought  into  the  Donavon  Process  Development  Method  and  are  now  plan¬ 
ning  to  integrate  existing  systems  into  it.  This  integration  should  take  six  months.  S&CG 
currently  has  IDMS  on  an  IBM  mainframe,  a  contract  cost  system,  a  program  scheduling 
system,  and  an  earned  value  utility.  These  applications  exist  in  SNA.  They  are  in  the  pro¬ 
cess  of  bridging  from  SNA  to  Unix  (POSIX)  and  will  include  110  users  in  4  divisions. 
Users  on  PCs  and  Macintoshes  will  also  be  included.  The  new  system  will  give  the  appear¬ 
ance  of  integration  with  the  bridges  existing  in  the  background. 

There  is  currently  an  EDI  effort,  motivated  by  the  ATF  contract  award,  to  connect 
customers.  But  Hughes  is  concentrating  on  both  internal  integration  and  external  EDI.  The 
company  has  recently  initiated  a  project  to  establish  a  common  Manufacturing,  Material, 
and  Acquisition  System  (MMAS)  to  support  its  aerospace  activities. 

Information  Infrastructure: 

At  Hughes  the  Groups  have  assessed  their  existing  systems  against  their  needs. 
They  built  a  matrix  of  business  processes  and  data.  It  showed  them  how  data  is  used  and  by 
whom. 

The  components  of  the  enterprise  integration  project  include  a  common  data  model, 
product  data  management,  and  common  parts  definition  and  libraries.  It  is  too  early  to  say 
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how  these  conqwnents  will  be  implemented.  Hughes  is  considering  buying  and  integrating 
and  then  tailoring  various  products. 

An  object-oriented  data  base  (OODB)  may  be  of  interest  later.  Right  now,  Hughes 
is  concentrating  on  the  process. 

Currently  the  vision  at  Hughes  is  that  it  will  be  eliminating  all  existing  legacy  sys¬ 
tems  with  open  systems  over  the  next  6ve  years. 

Hughes  strongly  supports  die  notion  of  a  national  standardization  initiative  that 
would  tie  networking  and  product  data  standards  together.  It  sees  OSF  (Open  Software 
Forum)  as  a  model  of  standardization  effort  effectiveness.  Hughes  also  participates  in  the 
PDES  standardization  efforts. 
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INTEL  CORPORATION 


Description  of  the  Business: 

Designer  and  manufacturer  of  microprocessors. 

Industry  1991: 

Business  Strategy: 

Business  strategies  at  Intel  are  driven  by  four  characteristics:  a  constantly  changing 
organization  (in  response  to  rapidly  changing  market  needs),  the  geographic  dispersal  of  its 
operating  units,  a  culture  of  bottom-up  consensus  building,  and  a  very  strong  “people”  net¬ 
work. 

The  decision  making  process  at  Intel  is  not  always  based  on  the  results  of  elaborate 
cost-benefit  analyses,  especially  when  providing  a  quantifiable  cost-benefit  analysis  is  very 
difficult  Rather,  employees  develop  compelling  arguments  in  support  of  a  position  and 
convince  the  relevant  groups.  The  arguments  are  often  based  on  intuition  and  experience, 
which  are  supported  by  hard  data  as  appropriate.  Arguments  may  be  driven,  for  example, 
by  market  trends  or  by  what  competitors  are  doing.  In  the  pursuit  of  enterprise  integration, 
Intel  sees  this  not  as  an  investment  issue,  but  rather  a  consensus  and  competition  issue. 

To  be  competitive,  Intel  recognizes  that  the  technology  processes  will  be  revised 
frequently,  possibly  every  two  or  three  years.  Thus,  the  very  large  investments  required  to 
develop  new  processes  and  build  new  wafer  fab  facilities  need  little  additional  justification 
for  senior  management  However,  within  a  given  technology  process  window,  the  decision 
to  build  a  specific  product  or  product  set  requires  substantial  justification,  especially  when 
demand  exceeds  process  capacity. 

Intel  believes  that  the  costs  associated  with  producing  a  product  are  in  materials, 
capital  and  facilities,  people,  and  transportation.  Issues  of  critical  importance  to  Intel  from 
the  cost  standpoint  are  yield  and  time-to-market  The  primary  cost  driver  in  any  product  is 
yield  or  possible  units  shipped.  The  secondary  cost  driver  is  time-to-market  In  this  area, 
Intel  has  implemented  some  aspects  of  concurrent  engineering  to  help  reduce  time-to-mar¬ 
ket 

Enabling  technologies  such  as  integrated  CAD  tools,  engineering  workstations, 
analysis  software,  fibre  optic  communications  links,  and  shop  floor  control  systems  will 
support  the  concurrent  engineering  strategy.  Begiiming  in  the  1980s  Intel  invested  heavily 
in  these  technologies  with  the  goal  of  cutting  one  year  off  product  development  time.  The 
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common  CAD  system  has  been  extensively  modified,  but  is  being  used  throughout  the  cor¬ 
poration. 

As  an  indication  of  the  divisional  and  geographical  independence  at  Intel,  there  are 
5  design  facilities,  8  fabrication  plants,  3  assembly  plants  and  15  test  groups.  The  initial 
logic  for  this  distribution  was  for  fabrication  to  be  done  in  the  United  States  since  it  was 
capital  intensive,  assembly  was  to  be  done  off  shore  as  it  was  labor  intensive,  and  testing 
was  to  be  done  in  the  United  States  as  it  needed  to  be  closely  monitored  by  the  U.S.-based 
engineers.  There  is  a  move  to  migrate  operations  out  of  Santa  Clara,  California,  due  to  ris¬ 
ing  costs  and  environmental  concerns.  As  a  result  of  the  geographical  dispersion,  logistics 
are  fairly  complex  but  are  not  supported  by  very  sophisticated  systems. 

State  of  Integration: 

Enterprise  integration  is  a  recognized  issue  at  Intel.  Management  believes  that  it 
needs  higher  level,  coherent  direction  to  solve  its  integration  problems.  It  feels  that  the  first 
step  in  integrating  the  enterprise  is  for  someone  to  model  the  enterprise  and  how  the  busi¬ 
ness  is  to  be  run.  A  senior  management  decision  on  how  integrate  must  then  be  made.  An 
area  of  concern  is  that  middle  management  cannot  get  the  attention  of  anyone  higher  up 
who  is  willing  to  take  this  first  step.  An  additional  concern  is  that  the  effort  to  develop  a 
solution  would  require  the  commitment  of  soirw  of  Intel’s  best  people,  all  coming  from  dif¬ 
ferent  organizations.  People  and  divisions  are  fairly  independent  within  Intel  and  do  not 
often  work  as  a  team  toward  global  (corporate)  benefits.  Intel  has  just  recently  started  to 
share  information  within  a  “team”  and  with  industry. 

Marketing,  manufacturing,  and  logistics  are  attenq>ting  to  develop  an  integrated 
sales  order  entry  system.  The  incentive  for  this  integration  is  to  improve  performance  to  the 
customer.  Management  at  Intel  estimates  that  it  will  be  one  and  one-half  years  to  get  con¬ 
sensus  on  this  effort,  however.  Implementation  will  then  take  an  additional  two  to  four 
years.  No  one  has  asked  what  the  cost  savings  will  be  as  a  result  of  this  system — the  benefits 
seem  intuitive  and  hard  to  quantify.  They  feel  it  is  “customer  justified.” 

Management  at  Intel  recognizes  that  control  of  material  is  the  one  of  the  biggest 
problems  to  be  solved.  It  has  developed  several  loosely  connected  material  control  systems. 
However,  the  bottom-up  culture  of  consensus  building  means  that  until  all  the  groups  indi¬ 
cate  that  this  is  a  major  concern,  Intel  Corporate  will  not  impose  a  centralized  approach. 
The  corporate  view  now  is  that  if  they  can  still  get  a  product  out  in  a  profitable  manner,  why 
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impose  a  centralized  system  that  requires  resources  now  being  utilized  in  delivering  prod¬ 
ucts  to  customers? 

At  Intel  products  tend  to  be  designed  by  a  small  (20  engineers),  well -integrated 
group,  working  with  process  development  groups.  Not  very  much  manufacturing  data  are 
integrated  between  product  and  process  development  and  manufacturing  groups.  On  the 
factory  floor,  shop  floor  control  data  are  relatively  available,  as  are  engineering  data,  in 
somewhat  integrated  systems.  There  are  many,  many  translators  and  interfaces  to  these  sys¬ 
tems.  Intel  is  currently  building  larger  islands  of  automation  out  of  many  smaller  ones. 

EDI  has  been  set  up  with  Intel  customers.  Intel  is  starting  to  put  its  smaller  vendors 
on  EDI.  In  general,  Intel  is  working  to  decrease  the  number  of  vendors— and  working  to 
tighten  and/or  improve  its  relationships  with  those  vendors.  Sales  order  entry  is  being 
replaced  by  modularizing  a  former  monolithic  system.  The  goal  is  that  this  will  help  later 
attempts  to  integrate  it  with  the  manufacturing  systems. 

Product  nomenclature  is  not  standardized.  There  are  10  to  13  major  product  nomen¬ 
clature  inconsistencies  Intel  is  willing  to  live  with  for  the  time  being. 

Integration  Strategies: 

The  strategy  at  Intel  is  to  encourage  a  bottom  up,  consensus-driven  approach  to 
decision  making.  Islands  of  automation  or  integration  grow  bottom-up  for  a  while  until  they 
gain  the  attention  of  senior  management  At  that  point  a  decision  to  integrate  or  consolidate 
comes  from  the  appropriate  division  or  corporate  management. 

Approximately  100  companies  make  up  the  key  accounts  at  Intel.  These  companies 
represent  about  one-half  of  the  dollar  volume  of  sales.  Intel  has  started  to  encourage  greater 
customer  involvement  especially  when  the  customer  seeks  product  changes.  In  one 
instance,  response  time  was  shortened  from  five  months  to  one  month.  In  general,  however, 
management  at  Intel  feels  that  response  time  is  poor. 

Information  Infrastructure: 

Intel  has  no  cross-divisional  database.  Marketing  has  the  closest  thing  to  a  corpo¬ 
rate-wide  database.  Divisions  and  Groups  use  their  own  data  representations.  Translators 
between  formats  do  not  always  exist  For  example,  10  to  1 3  major  different  product  nomen¬ 
clatures  exist  within  the  semiconductor  group.  Maybe  as  many  as  another  100  minor  ones 
exist  as  well.  No  standard  formats  exist. 
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Engineers  are  strongly  encouraged  to  solve  their  own  problems  (bottom-up).  This 
may  be  because  the  company  grew  up  as  a  result  of  a  strong  entrepreneurial  spirit  and  is 
related  to  the  strong  people  culture  at  Intel. 

There  is  an  integrated  CAD  tool  environment  into  which  the  mask  fabrication  sys¬ 
tem  is  dved.  Product  and  process  quality  data  is  available  on-line  (as  a  result  of  recent  inter¬ 
nal  demand). 

Intel  has  numerous  electronic  mail  systems  which  do  not  communicate  well — if  at 
all.  Low-level  managers  and  engineers  complained  about  this  situation  (to  no  avail).  Then 
Corporate  ran  into  problems  associated  with  having  so  many  non-communicating  sys¬ 
tems — and  the  systems  were  better  bridged  and  the  number  of  systems  reduced.  Conse¬ 
quently,  Intel  has  accepted  the  separate  islands  and  are  now  trying  to  combine  them  in  a 
coherent  fashion. 

Lessons  Learned: 

There  is  a  great  deal  of  concern  over  the  attitude  of  U.S.  vendors.  Vendors  are  seen 
as  not  being  as  responsive  as  the  Japanese  vendors.  U.  S.  industries  have  maintained  a  too 
near-term  vision. 

Intel  follows  a  five-year  plan.  Ten  to  fifteen  is  too  far  in  the  future.  It  does  track 
developments  in  key  universities,  schools  specializing  in  specific  areas,  or  universities 
close  to  their  facilities. 

The  recent  push  toward  quality  improvement,  including  the  Baldridge  award,  has 
seemed  to  help.  Improved  benchmarking  has  also  had  a  positive  effect. 

Industry  2001: 

Issues  and  Barriers: 

Intel  views  the  standards  world  as  being  a  massive  quagmire.  Order  is  needed  but 
it  is  not  clear  how  that  order  shall  be  provided. 
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INTERNATIONAL  BUSINESS  MACHINES  (IBM)  CORPORATION 


Description  of  Business: 

IBM  is  a  computer  maker,  software  developer,  systems  integrator,  networking  spe¬ 
cialist,  service  company,  and  more — a  federation  of  businesses  dedicated  to  helping  cus¬ 
tomers  work  smarter,  faster,  and  better. 

Since  IBM  is  a  federation  of  autonomous  businesses,  each  business  unit  visited  pre¬ 
sented  only  its  own  integration  practices.  In  this  report  we  cover  the  CIM  Integration,  IBM 
Engineering  Framework,  AD/Cycle^,  and  Systems  Object  Management  portions  of  IBM’s 
business.  This  does  not  purport  to  address  all  of  IBM’s  integration  practices  and  strategies. 

Industry  1993: 

Business  Strategy: 

The  world-wide  computer  industry  is  being  reshaped  by  fundamental  changes, 
including  trends  towards  smaller  computers  and  open  systems.  Customers  place  increasing 
value  on  software,  services,  and  integration  skills.  In  1991,  responding  to  these  changes, 
IBM  revised  its  business  structure  to  create  more  autonomous  and  responsive  business 
units.  It  is  reallocating  resources  to  growth  business,  reducing  costs,  and  increasing  the 
autonomy  of  IBM  business  units. 

IBM’s  Marketing  and  Services  businesses  are  increasingly  focusing  on  consulting, 
systems  integration  and  related  services.  Growth  areas  include  client-server  computing, 
networking,  RISC  technology  and  multimedia,  together  with  essential  software. 

Marketplace  demand  for  world-class  quality  at  competitive  prices  is  driving  cost 
and  manufacturing  capacity  reductions.  Clear  focus  and  speed  to  market  are  essential  for 
competitiveness.  Increasingly,  each  IBM  business  is  shaping  itself  to  its  own  marketplace 
disciplines. 

CIM  Integration: 

Business  Strategy: 

IBM’s  CIM  Integration  Center  provides  consulting  and  integration  services  for 
both  internal  and  external  customers.  The  CIM  Integration  Initiative  supports  a  partnership 
between  the  Industrial  Sector  Division  (ISD)  and  customers.  Feedback  and  guidance  is  pro- 

^  The  AD/Cycle  infonnadon  is  from  a  visit  to  IBM's  Santa  Teresa  Laboratory  in  1 99 1 .  The  remainder  of  the 
informadon  is  from  visits  in  1993. 
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vided  through  the  CIM  Steering  Committee,  the  Executive  Steering  Committee  (VP-level 
participation),  and  the  Integration  Project  Group  (three  external  customers  and  one  internal 
customer).  They  also  maintain  a  dialogue  with  nrajor  customers  world-wide. 

CIM  is  moving  to  providing  solutions  and  services  via  consulting  arrangements,  in 
addition  to  via  announced  products.  IBM  can't  support  a  product  forever.  Nor  can  it  just 
build  a  product  and  put  it  out  there.  Partnering  is  a  key  strategy. 

The  goal  of  partnering  is  to  provide  a  solution  now,  not  a  product  in  two  years.  Solu¬ 
tions  need  not  be  products  (which  must  go  through  the  product-approval  process).  Partners 
participate  in  defining  the  potential  product  (the  solution),  sh?*^  of  the  project, 

and  obtain  the  solution  before  the  product  is  announced.  The  Ci.  ...^^gration  Center  may 
prototype  a  solution,  but  they  don't  build  deliverables  unless  some  customers  are  involved 
as  partners. 

The  driving  force  is  ensuring  the  implementation  of  the  IBM  CIM  architecture  as 
an  open,  integrated  set  of  ISD  and  key  business  partner  CIM  Advantage  offerings.  This 
architecture  will  provide  integrated  environment  and  support  services,  integrated  valida¬ 
tion,  integrated  requirements  definition,  and  development  of  selected  integrated  software. 

CIM  Application  Consulting  Services  (CACS)  is  a  six-person  team,  formed  in  May 
1992,  to  work  on  what  it  takes  to  deliver  integration  and  to  identify  gaps  and  overlaps 
between  hardware  and  software  products.  CACS  integrates  ISD  applications  in  manufac- 
mring  industries  and  performs  integration  studies. 

State  of  Integration: 

IBM  has  the  same  integration  problems  as  everyone  else.  The  CIM  Demonstration 
Lab  has  a  configuration  of  heterogeneous  hardware  and  software;  for  example,  hardware 
ranges  from  a  3090  mainframe  to  data  collection  equipment.  By  integrating  products  in  a 
realistic  business  scenario,  the  staff  builds  expertise  and  broad  experience  providing  inte¬ 
gration  services.  The  scenario  shown  to  the  IDA  electronics  team  demonstrated  a  product 
revision  under  engineering  change  control.  (IBM  stated  that  most  customers  acknowledge 
that  change  management  is  a  serious  issue.)  The  scenario  was  developed  with  the  Integra¬ 
tion  Project  Group,  and  involved  IBM  and  non-IBM  hardware  and  software.  The  scenario 
uses  a  data  model  driven  approach.  The  “target”  enterprise  provides  the  model.  Obtaining 
a  consensus  data  model  is  difficult. 

Bridging  among  network  systems  is  non-trivial.  In  the  Distributed  Application 
Environment  (DAE),  users  can  send  and  receive  messages  across  heterogeneous  networks. 
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Messages  can  be  sent  from  applications  to  users,  users  to  applications,  and  even  to  devices 
to  handle  an  event.  The  CIM  Integration  Center  uses  DAE  as  the  heart  of  its  distributed 
capability. 

Integration  Strategies: 

The  CIM  Integration  Center  is  in  the  infrastructure  business,  as  an  integrator  of 
IBM  and  non-IBM  environments. 

Information  Infrastructure: 

Team  Integration  Environment  (TIE)  is  a  collection  of  services  used  by  IBM  for 
CIM  integration.  TIE  services  include  Common  Data  Facility  (CDF),  Distributed  Applica¬ 
tion  Environment,  Concurrent  Engineering  (CE),  Services  Access  Interface  (SAI),  User 
Interface  (UI),  and  Information  Server  SAI. 

SAI  uses  “adaptors”  to  encapsulate  applications  to  the  standard  interface.  Current 
adaptors  are  focused  to  existing  applications.  The  strategy  is  to  make  the  adaptors  generic. 
If  future  applications  are  written  to  object-oriented  standards,  adaptors  will  be  easier  to 
write. 

DAE  is  a  messaging  system  with  queuing  capability  and  system  alerts.  It  provides 
portability  for  communications  services,  data  services,  user  services,  and  device  services; 
DAE  takes  care  of  network,  time,  threads,  and  messaging.  DAE  is  presently  a  proprietary 
implementation  but  will  evolve  towards  a  distributed  computing  environment  (DCE). 

UI  targets  “integration  at  the  glass,”  point-and-click  integration.  By  encapsulating 
applications  via  adaptors,  engineering  management  information  can  be  extracted  from  each 
application  and  presented  to  the  user  with  common  look  and  feel,  including  some  mouse- 
based  functions.  (Note:  this  common  look  and  feel  is  supported  in  a  separate,  TIE  UI  win¬ 
dow,  and  does  not  imply  that  the  application  running  in  its  own  window  conforms  to  the 
TIEUI.) 

In  the  CIM  Integration  Lab  demo,  the  Long  Data  Reference  Option  (LDRO)  from 
Product  Manager  is  used  for  engineering  management  of  data  from  encapsulated  applica¬ 
tions.  Kl-Shell  is  used  to  follow  the  demo’s  engineering  change  methodology.  This  is  a  pro¬ 
cess  model  driven  system,  but  the  user  provides  the  model.  Designing  this  model  is  the  hard 
part. 

IBM  is  the  largest  CATIA  user  in  the  world,  and  is  probably  the  largest  CADAM 
user  in  the  world  as  well. 
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The  CIM  Integration  Center  is  supporting  PDES/STEP. 

Electronic  CAD: 

Business  Strategy: 

Technology  Products’  CAD  Systems  Solutions  and  Frameworks  Program  provides 
electrical  CAD  tools  and  the  IBM  Engineering  Framework  (lEF),  and  supports  electrical 
CAD  tool  integration  for  IBM  divisions. 

State  of  Integration: 

IBM’s  Electronic  Design  Application  (EDA)  environment  (in  the  mid- 1 980 ’s)  ran 
on  mainframes  under  the  MVS  operating  system.  As  divisions  began  buying  more  outside 
parts,  they  also  started  to  acquire  outside  CAD  software.  The  CAD  group  saw  a  breakdown 
of  its  large,  established  (internal)  customer  base.  Although  the  MVS  system,  which  execut¬ 
ed  as  a  sequence  of  batch  steps,  appeared  integrated  to  its  users,  it  comprised  over  100  pro¬ 
grams  and  file  formats,  and  was  difficult  to  integrate  with  outside  software.  The  MVS 
system  involved  over  three  million  lines  of  code  written  in  proprietary  languages. 

The  CAD  group  decided  to  implement  a  platform  independent  system  written  in 
standard  languages  (C  or  C-H-).  It  tried  to  move  to  centralized  database  approach,  an  inte¬ 
grated  system  around  an  integrated  data  model.  This  proved  to  be  somewhat  unwieldy,  so 
it  followed  the  tack  of  integrating  multiple  tools  into  multiple  frameworks,  and  using  the 
tools’  databases  as  views  on  a  composite  virtual  repository.  Now  the  CAD  Group  is  inte¬ 
grating  point  tools  into  frameworks,  and  integrating  frameworks  into  the  IBM  Engineering 
Framework. 

Integration  Strategies: 

IBM  has  extensive  direct  involvement  in  the  CAD  Framework  Initiative  (CFI) 
working  groups,  to  generate  interest  within  CFI  in  concurrent  engineering  and  to  inriuence 
CFI  to  work  with  other  standards  bodies.  The  lEF  is  compliant  with  the  CFI’s  Standards 
Release  1.0  for  Inter-Tool  Communication  (ITC),  Computing  Environment  Services,  and 
Tool  Encapsulation  Specification  (TES). 

IBM  has  a  corporate  culture  to  use  division-specific  “standard”  design  methodolo¬ 
gies  within  a  design  group,  but  does  not  dictate  corporate-wide  IBM-standard  methodolo¬ 
gies.  However,  many  IBM  sites  are  not  using  a  single  design  methodology  and  tool  suite. 

IBM  will  go  through  ISO  9000  certification;  several  groups  have  already.  IBM  has 
many  European  Labs  and  European  customers,  so  they  have  followed  ISO  9000  as  it 
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emerged,  IBM's  rationale  for  conformance  is  to  sell  products  in  Europe  (IBM  Europe  com¬ 
panies  are  European;  95%  of  what  is  sold  in  Europe  is  made  in  Europe.)  The  biggest  effect 
of  1809000  will  be  on  engineering  change  procedures,  but  overall  it  will  not  require  much 
change  for  IBM. 

Information  Infrastructure: 

Ten  years  ago,  IBM’s  EDA  environment  ran  on  mainframes  under  the  MVS  oper¬ 
ating  system.  Some  of  these  tools  continue  in  use  today.  In  addition  divisions  are  using  out¬ 
side  CAD  software.  Suites  of  point  tools  that  are  used  together  are  integrated  into 
workbenches.  There  are  CASE  workbenches,  ECAD  front-end  workbenches,  and  so  forth. 
The  CASE  workbench  might  be  integrated  through  a  PCTE  framework,  while  an  EDA 
workbench  might  be  IBM  internal  tools  under  lEF,  Cadence  tools  under  Design  Framework 
II,  or  Mentor  Graphics  tools  under  Falcon  Framework.  Workbenches  (and  their  domain-ori¬ 
ented,  proprietary  frameworks)  are  integrated  as  clients  under  the  lEF  server. 

IBM  has  developed  a  VHDL-oriented  workbench  of  EDA  front-end  tools  (under 
lEF).  It  has  added  a  “d  esktop”  interface  that  presents  design  status,  process  control,  session 
status,  and  an  error  bi  owser.  The  error  browser  runs  in  a  standard  window  that  is  used  by 
all  tools  for  error  rept  rting, 

IBM  connects  to  suppliers  by  the  IBM  Information  Network  Services.  Security  is 
not  an  issue  because  a  ligorous  security  methodology  is  in  place. 

Application  Development: 

Business  Strategy: 

AD/Cycle  is  IBM’s  Application  Development  strategy  for  Systems  Application 
Architecture  (SAA).  SAA  crosses  mainframe  (System/370),  AS/400  and  PS/2  computers 
under  MVS  and  VM,  OS/400,  and  OS/2  operating  systems,  respectively.  They  are  becom¬ 
ing  interested  in  extending  AD/Cycle  to  support  ADC  (Unix)  machines. 

IBM  has  established  a  customer  advisory  council  on  AD/Cycle.  The  members  have 
two  representatives  on  the  council:  one  at  the  QO  level  and  one  at  the  technical  level.  The 
CIO  level  council  members  advise  on  strategy. 

State  of  Integration: 

AD/Cycle  is  characterized  as  a  repository  manager  plus  tools,  supporting  multiple 
languages  and  providing  a  knowledge-based  system.  The  architecture  diagram  for  AD/ 
Cycle  is  depicted  in  Figure  E-1. 
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[  AD/Cycle  Tools 

Cross  Life  Cycle  Activities 

Application  Developt^ent  Life  Cycle 

PLATFORM 

Figure  E*l.  AD/Cycle  Architecture  Diagram 


AD/Cycle  enables  developers  to  apply  clean  room  methods  to  application  develop¬ 
ment 

The  platform  component  of  the  architecture  includes  the  Repository  Manager  (e.g., 
RM/MVS)  and  lilvary  services  of  the  Software  Configuration  and  Library  Manager 
(SCLM).  Both  of  these  work  with  the  AD  Information  Model  which  is  an  Entity-Relation¬ 
ship-Attribute  -I-  Constraints  model  that  provides  a  predefined  extendible  base  model  for 
AD/Cycle  developed  qrplications. 

An  example  of  Cross  Life  Cycle  services  is  process  control  &om  the  Application 
Development  Project  Support  (ADPS)  program. 

An  example  of  an  Application  Development  Cross  Life  Cycle  tools  is  an  SA/SD 
(Structured  Analysis/Structured  Design)  dataflow  tool.  Some  of  the  AD  Ooss  Life  Cycle 
tools  are  provided  by  third-party  parmers,  such  as  Knowledgeware  (Application  Develop¬ 
ment  Workbench,  ADW),  Bachman  Information  Systems,  and  Intersolv  (Excelerator  prod¬ 
ucts). 

ADW/MVS  REF  (or  ADW/REF)  Repository  Enablement  Facility  is  an  application 
to  the  Repository  Manager.  ADW/REF  adheres  to  the  AD  information  model.  ADW/REF 
interfaces  ADW’s  entity  aggregations  to  RM  repository  objects.  Repository  objects  provide 
a  flat  interface  to  various  media,  such  as  optical  disks  and  libraries. 

Integration  Strategies: 

AD/Cycle  is  a  collection  of  software  tools  that  provide  an  Application  Develop¬ 
ment  environment  that  address  the  entire  life  cycle.  AD/Cycle-developed  applications  exe¬ 
cute  in  the  context  of  many  other  software  systems,  such  as  CTM,  ADC/CASE,  System 
View,  Image+,  and  Office  >^ew.  In  developing  die  architecture  for  AD/Cycle,  a  goal  was  to 
identify  integration  services  that  serve  all  of  these  application  areas,  for  example,  the  RM. 
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Information  Infrastructure: 

The  AD/Cyclc  information  model  has  three  levels  of  models;  Enterprise  model. 
Technology  model,  and  Global  model. 

The  Enterprise  model  deals  with  process,  information  flow,  entity  relationship,  and 
so  forth. 

The  Technology  model  deals  with  business  modeling  and  application  modeling.  It 
follows  John  Zachman’s  framework  model.  Views  include: 

•  DRC,  Database  Relational  Common 

•  DRM,  a  DB2  unique  extension  of  DRC  (M  denotes  MVS) 

•  DL 1 ,  for  IMS  (Information  Management  System) 

•  High-level  language  (HLL)  Cobol,  for  Cobol  data  structures 

•  APT,  Application  Programming  Technology 

APT  is  library  oriented,  dealing  with  parsed  source  code,  denormalization,  and  data 
definition  language.  The  Global  model  is  a  data  dictionary  with  descriptive  text.  It  describes 
entities  at  the  level  of  an  RM  object  Relationships  are  possible  across  layers  of  the  infor¬ 
mation  model,  for  example,  to  support  object-oriented  analysis  and  design.  Conformance 
to  the  information  model  is  enforced  at  three  levels,  depending  on  the  level  of  integration: 
Conunon  User  Access  (for  external  users),  Tool-to-Tool  Control  How  and  Data  Integra¬ 
tion. 

The  RM  is  a  system  for  managing  specifications.  For  the  specification  domain,  RM 
uses  a  three-level  data  architecture  with  conceptual,  storage,  and  logical  views.  For  the  run¬ 
time  domain,  RM  provides  data  services,  user  services,  and  systems  services. 

Data  services  support  reading  and  writing  entities,  relationships  and  attributes 
through  a  tool’s  logical  data  view.  User  services  supports  automatic  mapping  from  RM 
template  fields  to  Dialog  Manager  panel  fields  and  other  services  in  the  logical  view  for 
Dialog  Manager  I/O  operations. 

System  Services  support  RM  functions.  This  includes  binding  functions  and  meth¬ 
ods  to  templates,  dynamically  binding  templates  to  entity  sets,  opening  and  closing  func¬ 
tions,  and  invoking  functions  and  methods.  RM  objects  provide  method  inheritance,  but  not 
data  inheritance.  There  are  no  persistent  identifiers  for  RM  objects. 
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Object  Management: 

Business  Strat^: 

System  Object  Management  (SOM)  provides  portable,  language-neutral  object 
technology.  The  goal  for  SOM  was  to  provide  objects  in  OS/2  without  an  object-oriented 
programming  language.  Distributed  SOM  (DSOM)  extends  SOM  objects  to  interoperate 
with  objects  located  across  a  local  or  internet  network.  IBM  is  very  open  with  SOM  tech¬ 
nology.  They  see  DSOM  as  a  ubiquitous  part  of  the  information  infrastructure.  They  will 
port  to  certain  non-IBM  environments  (e.g.,  DOS)  and  are  willing  to  talk  to  everybody 
about  making  the  technology  widely  available. 

Information  Infrastructure: 

SOM  provides  portable,  language  neutral  object  management  SOM  is  portable  in 
that  for  systems  objects  there  will  be  a  common  API  across  DOS,  OS/2,  AIX,  and  Taligent. 
SOM  is  language  neutral  in  that  the  methods  for  an  object  class  can  be  written  in  any  lan¬ 
guage  (for  which  there  are  SOM  bindings),  even  to  the  extent  that  each  method  can  be 
implemented  in  a  different  language.  To  do  this,  IBM  developed  the  SOM  binding  technol¬ 
ogy,  which  resolves  linking  (to  a  binary  executable  in  a  library)  and  solves  the  library  com¬ 
patibility  problem. 

SOM  is  a  component  of  OS/2.  SOM  objects  are  defined  using  the  Common  Object 
Request  Broker  Architecture  Interface  Definition  Language  (CORBA  IDL).  SOM  is  the 
only  object  strategy  that  is  not  tied  to  a  specific  implementation  language.  Presently  there 
are  SOM  language  bindings  for  C,  OO-Cobol,  C-M-,  and  SmallTalk- V.  For  languages  with¬ 
out  SOM  bindings,  a  SOM  adaptor  can  be  written  for  a  non-SOM  object  so  that  its  methods 
can  also  be  invoked  through  SOM. 

Distributed  SOM  (DSOM)  allows  invocation  of  object  services  (methods  on  a  SOM 
object)  anyplace  in  a  network,  in  a  location  transparent  manner.  DSOM,  which  is  CORBA 
compliant,  is  now  based  on  sockets,  but  will  evolve  to  DCE.  IBM  will  submit  DSOM  to  the 
Object  Management  Group  (OMG)  as  a  reference  implementation  of  CORBA.  Also,  IBM 
and  Hewlett-Packard  are  proposing  extensions  to  CORBA  that,  if  accepted  by  OMG,  will 
ensure  that  CORBA-compliant  objects  can  interoperate. 

Lessons  Learned: 

•  Business  processes  are  changing  faster  than  Information  Systems  can  keep  up. 

•  A  company  may  be  a  supplier,  a  prime,  and  a  competitor  all  at  the  same  time. 
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•  Nobody  builds  anything  at  only  one  place  anymore. 

•  With  respect  to  integration  infrastructures,  industrial  sector  vs.  non-industrial 
sector  is  a  marketing  distinction,  not  a  technological  distinction. 

•  Islands  of  automation  are  no  longer  sufficient.  Customers  want  information 
exchange  between  islands  of  automation;  interfaces  are  required. 

•  There  are  problems  in  two  places:  networking  and  presentation.  Messaging  to/ 
from  functional  servers  and  designing  data  models  and  databases  to  work  in  this 
environment  are  hard  problems.  Porting  application  interfaces  is  in  hours  and 
days;  porting  presentation  is  in  weeks  and  months.  The  data  model  and  structure 
affect  performance. 

•  Standards  dealing  with  data  visibility,  and  data  exchange  are  the  most  important 
to  support  integration.  There  is  a  need  for  standards  progress  on  presentation. 

•  For  integration  infrastructures,  90%  of  the  innovation  is  done.  Only  the  imple¬ 
mentation  remains,  which  must  be  driven  by  users’  priorities. 

•  The  technologies  required  for  integrated  infrastructures  are  currently  available. 
The  challenge  will  be  to  develop  a  strategy  for  selecting  from  the  wide  variety 
of  available  technologies  to  ensure  that  the  appropriate  components,  applica¬ 
tions,  and  standards  are  used  in  implementing  the  integrated  infrastructures. 

•  A  key  requirement  is  to  work  with  existing  legacy  applications,  allowing  migra¬ 
tion  to  new  technologies.  A  legacy  system  is  either  (1)  an  older,  existing  system, 
or  (2)  any  system  where  the  data  is  integrated  with  the  application.  A  “new”  sys¬ 
tem  could  be  a  legacy  system. 

•  Push/pull  depends  on  an  application’s  capability.  A  pull  capability  plus  an 
appropriate  message  and  user  action  approximates  push. 

•  Object  Management  Systems  are  six  to  nine  months  out;  object-oriented  data¬ 
bases  are  not  necessary  to  obtain  the  benefits  of  objects  for  integration.  The  CIM 
Integration  Center  group  sees  existing  object  management  technology  plugging 
in  at  departmental  level,  but  feel  that  current  object  databases  are  not  suitable 
for  enterprise  level  solutions. 

•  CIM  compliance  with  OMG’s  CORE  A  is  a  requirement  (raised  by  heavy  equip¬ 
ment  manufacturers). 
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•  Development  of  new  high-speed  components  has  the  effect  of  blurring  lines 
between  validation,  test,  synthesis,  design,  etc.,  and  of  blurring  the  distinction 
between  electrical  and  mechanical  design.  IBM  had  to  develop  better  coupling 
between  engineering  and  test,  which  required  greater  emphasis  on  Concurrent 
Engineering. 

•  Design  engineers  resist  standard  methodologies  because  they  fear  that  standard¬ 
ization  may  take  the  “art”  out  of  engineering  (they  want  to  keep  the  artistic  part 
of  design). 

•  Integration  of  point  tools  into  large  systems  is  difficult. 

•  It  is  impractical  to  believe  that  people  will  give  up  their  point  tools  to  move  to 
standard  tools.  Engineers  would  rather  have  faster  point  tools  than  closer  inte¬ 
gration  with  other  disciplines. 

•  It  is  impractical  to  believe  that  people  will  go  to  federated  databases.  An  enter¬ 
prise  will  probably  retain  many  separate  databases. 

•  IBM  is  doing  less  outsourcing  of  design  work  now,  in  part  to  keep  people 
employed. 

•  One  wants  the  enteiprise’s  integrated  data  model  to  grow  incrementally.  An 
enterprise  process  model  is  the  guide  to  consistent  incremental  growth.  Don’t 
push  data  models  as  standards;  instead,  pursue  a  process  modeling  standard. 

•  Change  management  is  an  application  issue.  The  ability  to  conununicate  change 
in  related  pieces  of  data  is  within  our  grasp.  Three  facets  of  dealing  with  change 
are  (1)  to  minimize  the  amount  of  change  due  to  errors,  (2)  to  recognize  that 
external  influences  will  cause  change  (some  rapid,  some  controlled),  and  (3) 
that  the  dynamics  of  thousands  of  applications  will  require  change. 

•  Right  now,  even  developing  shops  aren't  using  their  own  frameworks;  a  test  of 
success  is  when  they  do.  Not  everyone  will  be  on  one  firamework. 

•  Communicating  information  among  applications  is  central  to  integration.  CIM: 
DAE  provides  necessary  communications  services.  EDA:  Inter-Tool  Commu¬ 
nication  is  the  center  of  a  framework.  And  SOM;  cut  and  paste  are  required  in 
all  applications. 

•  The  functionality  of  frameworks  is  moving  into  operating  systems. 
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•  IBM  has  invested  a  lot  in  past  standards  work  and  has  occasionally  been  burned 
(e.g..  Jovial). 

•  SOM  enables  programmers  to  utilize  their  training,  whether  in  C,  Cobol,  C++, 
or  SmallTalk- V.  There  need  be  only  a  few  specialized  object  designers,  who 
might  have  to  be  retrained. 

•  Some  CORBA-compliant  products  work  well  in  a  homogeneous  environment 
but  do  not  interoperate  well  with  objects  in  a  different  CORBA  environment. 
CORBA  is  necessary  but  not  sufficient 

Industry  2001: 

Vision: 

IBM  is  pursuing  a  concunent  engineering  vision  for  1997. 

Application  families  must  be  commodity  items.  We  need  a  structured  approach  for 
integrating  inconsistent  environments.  There  must  be  (application  family  specific)  standard 
interfaces  so  that  the  applications  remain  modular  within  an  integrated  system.  An  IBM  PC 
VP  was  quoted  as  having  said  that  “the  time  will  come  when  IBM  will  only  purchase  soft¬ 
ware  that  meets  standards.” 

In  2001,  systems  will  contain  a  mix  of  relational  and  object-oriented  databases. 
They  will  also  have  a  mixture  of  procedural  and  object-oriented  applications.  An  integra¬ 
tion  framework  or  reference  integration  architecture  is  necessary  to  handle  it  all. 

In  the  future  you  will  have  “some  of  everything”  and  you  must  have  an  information 
technology  structure  that  lets  you  evolve.  A  parametric  services  workbench  could  put 
parameters  under  engineering  management,  providing  levels  of  authorization,  lock,  con¬ 
trols,  and  so  forth. 

There  are  levels  of  integration:  workbench  integration  integrates  tools  into  work¬ 
benches,  discipline  integration  integrates  workbenches  into  disciplines,  and  enterprise  inte¬ 
gration  integrates  disciplines  into  the  enterprise. 

Object  technology  in  the  infrastructure  will  enable  existing  technology  to  plug  in 
and  use  the  infrastructure  to  expand  to  the  enterprise  level.  Business  processes  will  also  be 
represented  as  objects. 
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A  “framework”  as  the  integration  of  multiple  applications  frameworks  tied  together 
with  standard  message  scheme  (according  to  CFI)  is  a  feasible  way  to  build  an  engineering 
framework. 

Future  Information  Infrastructures: 

For  portability,  TIE  is  targeting  DCE  which  takes  care  of  a  lot  of  necessary  system- 
level  services  (backup,  security,  etc.). 

Requirements  for  Structured  Architectural  Approach  include: 

•  client/server 

•  heterogeneous  data 

•  open  system  environment 

•  full  API  at  application 

•  high-level/stable  API 

•  large  objects^ 

•  complex  objects 

•  network  transparency 

•  information  directory 

The  functionality  of  frameworks  is  moving  into  operating  systems. 

DSOM  will  be  a  ubiquitous  component  of  the  information  infrastructure,  providing 
portable  object  services  across  all  the  popular  computing  platforms. 

Applications  will  be  developed  as  specializations  of  “application  frameworks.”  An 
application  fTamework"^  is  an  application  that  is  designed  to  be  extended  by  subclasses.  It 
includes  a  library  of  classes  plus  a  sample  application  that  uses  the  library.  That  is,  an  appli¬ 
cation  framework  includes  user  interface,  file  housekeeping,  cut  and  paste,  networking, 
links,  plus  “the  algorithm.” 


^  IBM  referred  to  experience  with  a  345  Megabyte  object  at  one  customer. 

^  The  Application  Framework  approach  is  being  developed  by  Taligent,  a  joint  venture  between  IBM  and 
Apple  Computer.  Taligent  will  be  providing  a  rich  set  of  framewoiks  and  objects;  currently  24  frameworks. 
2,000  objects. 
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Issues  and  Barriers: 

There  is  a  need  to  reach  agreement  on  meta-models  and  communications;  a  meta¬ 
standard  would  help  to  consistently  harmonize  competing  standards. 

Recommendations: 

Industry: 

The  lEF  group  is  heavily  involved  in  standards.  It  has  been  active  in  the  CFl  since 
1989,  and  is  working  with  the  electrical  side  of  PDFS.  The  IFF  Group  see  that  these  stan¬ 
dards  are  beginning  to  overlap.  IBM  propo.ses  that  where  there  are  similar  concerns,  the  dif¬ 
ferent  standards  efforts  collaborate  on  joint  pilot  projects. 

CFI  needs  to  focus  on  integrating  engineering  activities  (concurrent  engineering) 
rather  than  just  focus  on  integrating  tools. 

IBM  would  like  to  see  things  better  in  the  standards  arena.  Suppliers  must  get 
together  and  be  collaboratively  involved  in  standards  development  to  prevent  losing  their 
technical  autonomy  to  the  bigger  customers. 

Government: 

Scalability  is  the  key  to  moving  complex  software  (e.g.,  CAD  tools)  onto  smaller 
computers.  The  Advanced  Research  Projects  Agency  (ARPA)  has  a  role  in  studying  tech¬ 
nology  support  for  scalability. 

Large  companies  cannot  solve  all  the  country’s  problems — government  must  push 
standards  and  business  practices  all  the  way  down  to  suppliers,  where  it  is  in  the  country’s 
best  interest.  Government  should  insist  on  standards  or  refuse  to  buy  non-compliant  prod¬ 
ucts. 
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MOTOROLA  CELLULAR  SUBSCRIBER  GROUP 


Description  of  the  Business: 

This  division  of  Motorola  designs  and  manufacturers  a  line  of  cellular  phone  prod¬ 
ucts. 

Industry  1991: 

Business  Strategy: 

The  Management  of  Information  Systems  (MIS)  group  put  together  the  plan  (in 
excess  of  $1  million)  to  develop  a  Material  Control  System  (MCS)  system.  It  is  unclear 
whether  a  cost-benefit  analysis  was  performed  prior  to  implementation.  However,  initial 
results  indicate  that  it  will  result  in  significant  savings. 

State  of  Integration: 

The  manufacturing  resource  n;anning  (MRP)  or  material  control  system  (MCS)  has 
42  modules  and  is  hosted  on  an  IBM  mainframe.  Motorola  Cellular  Subscriber  Group 
(MCSG)  is  in  the  process  of  moving  it  to  a  distributed  Unix  system.  All  the  legacy  databas¬ 
es  will  be  moved  to  a  relational  database.  The  material  control  system  portion  of  the  system 
should  be  converted  in  six  to  eight  months.  The  new  MCS  will  have  greatly  increased  func¬ 
tionality. 

Electronic  EDI  is  now  in  place.  It  has  resulted  in  major  cycle  time  reductions.  For 
instance,  five  to  six  weeks’  worth  of  work  is  now  compressed  into  one  week.  Engineering 
teams  are  organized  by  market  orientation.  They  are  taught  to  “live  and  breath”  the  market 
place.  This  has  had  a  major  impact  on  efficiency  at  MCSG.  EDI  is  now  being  pursued  with 
customers  and  suppliers. 

Supplier  EDI  will  include  inventory,  inventory  requirements,  and  orders.  However, 
the  semiconductor  group  within  Motorola  has  a  different  EDI  system.  Motorola  Cellular 
prefers  to  continue  to  use  its  own  system.  Printed  circuit  board  (PCB)  information,  the  larg¬ 
est  component  of  the  engineering  effort  at  Cellular  Subscriber  Group,  is  shared  electroni¬ 
cally  with  the  supplier. 

MCSG  is  decreasing  the  number  of  its  suppliers.  This  number  currently  stands  at  50 
to  75  key  vendors.  MCSG  is  tending  to  drive  its  EDI.  However,  due  to  an  overlap  in  their 
markets  some  suppliers  are  being  driven  by  automotive  EDI.  Cellular  Subscriber  Group  is 
very  interested  in  pursuing  EDI  with  customers.  However,  it  is  not  yet  in  place. 
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MCSG  is  continuing  to  automate  its  manufacturing.  Component  placement  infor¬ 
mation  is  electronically  supplied  at  the  assembly  site.  A  physical  model  of  how  a  product 
is  built  has  been  replaced  by  on-line  build  information  including  a  screen  image  of  the  prod¬ 
uct  and  assembly  instructions.  Motorola  Cellular  is  implementing  a  factory  control  system 
(FCS).  The  goal  is  to  speed  up  new  product  introduction  by  decreasing  the  time  from  prod¬ 
uct  design  to  factory  programming.  This  system  is  part  of  the  MCS  and  uses  the  same  data¬ 
base.  MCSG  uses  Motorola  platforms  and  writes  its  own  software  for  the  manufacturing 
FCS.  The  system  is  Unix  based.  Not  all  of  its  CASE  tools  are  ported  to  the  Motorola  plat¬ 
forms.  Therefore,  many  CASE  tools  are  not  available.  The  result  of  MCSG  efforts  thus  far 
is  a  decrease  in  the  cycle  time  from  five  weeks  to  one  week. 

The  machine  programs  controlling  the  production  lines  on  the  factory  floor  can  be 
changed  in  hours.  MCSG  production  lines  are  set  up  for  producing  250  different  kinds  of 
boards  in  lot  sizes  of  10.  They  are  able  to  produce  600  to  800  boards  per  day  using  2  shifts. 

MCSG  uses  a  Contracting  Book.  Hiis  is  a  document  of  contracting  specifications 
that  includes  ordering,  manufacturing,  and  delivery  agreements.  Once  the  details  of  the 
agreement  have  been  negotiated  and  settled,  the  terms  serve  as  a  contract  for  all  the  players, 
both  internal  and  external.  The  Contracting  Book  will  be  converted  to  electronic  format. 

Cellular  Subscriber  Group  uses  simulations  to  optimize  manufacturing.  By  identi¬ 
fying  machines  that  were  not  needed,  the  simulations  have  saved  millions  of  dollars.  This 
has  resulted  in  a  10%  improvement  in  operations  on  the  manufacturing  floor. 

Information  Infrastructure: 

The  legacy  database  currently  in  use  at  MCSG  is  being  moved  to  a  relational  data¬ 
base. 

Issues  and  Barriers: 

CAD  tool  integration  has  been  a  problem.  The  issue  is  whether  the  tool  is  Unix  or 
IBM  based. 

The  next  step  in  the  vision  is  to  somehow  solve  the  problem  of  rapidly  changing 
operating  systems  and  platforms.  MCSC  spends  40  to  50%  of  its  operating  budget  to  keep 
up  with  rapidly  changing  technologies. 

When  the  Cellular  Subscriber  Group  was  started  as  an  independent  operation,  it  was 
directed  to  use  Motorola  products  in  the  cellular  phone  product.  Since  Motorola  divisions 


operate  autonomously,  dealing  with  other  divisions  in  the  company  sometimes  resembles 
dealing  with  an  outside  company. 


E-32 


E.7 


MOTOROLA  CORPORATE 


Description  of  the  Business: 

Motorola  Corporation  is  a  leading  provider  of  electronic  equipment,  systems,  com¬ 
ponents  and  services  for  world-wide  markets.  Products  include  two-way  radios,  pagers, 
cellular  telephone  systems,  semiconductors,  defense  and  aerospace  electronics,  automotive 
and  industrial  electronic  equipment,  computers,  data  communications,  and  information 
processing  and  handling  equipment. 

This  visit  concentrated  on  the  views  of  Motorola  Corporate  Headquarters  regarding 
enterprise  integration  company  wide. 

Industry  1991: 

Business  Strategy: 

Divisions  within  Motorola  are  very  autonomous  with  regard  to  both  their  manage¬ 
ment  and  direction,  as  well  as  their  finances.  The  belief  is  that  smaller  groups  can  be  more 
responsive  to  changing  markets  and  technologies. 

The  feeling  at  Motorola  Corporate  is  that  historically  Motorola  did  not  need  to  inte¬ 
grate.  The  business  was  generating  a  profit  and  seemed  responsive  to  changing  markets. 
The  payback  for  the  investment  required  for  enterprise  integration  was  not  clear.  The  pay¬ 
back  is  now  clear  however.  By  implementing  enterprise  integration,  greater  economies  of 
scale  can  be  achieved.  Previously,  the  Semiconductor  Products  Sector  Group  and  Corporate 
Staff  were  pursuing  integration  as  separate  entities,  whereas  now  they  collaborate. 

The  integration  of  the  electronic  mail  systems  was  proposed  to  save  money.  Motor¬ 
ola  did  not  know  how  much  it  would  save,  but  they  were  confident  the  savings  would  be 
significant.  It  now  looks  like  it  is  saving  more  than  they  expected. 

State  of  Integration: 

Currently  four  separate  customer  order  fulfillment  (COF)  projects  are  ongoing  at 
Motorola  Corporate.  This  is  because  everyone  thinks  their  problem  is  unique.  Corporate 
currently  supports  19  to  21  major  platforms. 

An  electronic  mail  application  is  the  first  enterprise  integration  project  to  be 
attempted  at  Motorola  Corporate.  Electronic  mail  is  currently  running  as  an  enterprise  util¬ 
ity.  The  goal  is  to  move  from  a  centralized  “post”  system  to  a  distributed  system.  The  entire 
electronic  mail  problem  stems  from  the  divisional  autonomy.  Motorola  has  teamed  with 


two  customers/supplicrs  (DEC  and  IBM)  to  complete  the  electronic  mail  project.  DEC  will 
provide  the  platforms. 

The  Information  Technology  Management  Group  is  also  planning  a  roadmap  for 
enterprise  integration.  The  plan  is  not  fully  in  place  yet.  But  with  a  goal  of  a  wall-less  work 
space,  the  group  is  beginning  with  office  data  and  documents  (e.g.,  spreadsheets).  It  is  not 
yet  considering  engineering  information  at  all,  as  it  is  believed  to  be  a  much  harder  prob¬ 
lem. 

Motorola  has  data  and  a  case  history  showing  decreased  costs  and  a  50%  decrease 
in  cycle  time  resulting  from  enterprise  integration.  These  figures  all  relate  to  integrated  cir¬ 
cuit  production. 

Motorola  has  reduced  the  time  required  to  produce  sales  catalogs  from  two  weeks 
to  being  able  to  produce  them  in  real  time. 

Integration  Strategies: 

The  electronic  mail  system  is  inappropriate  for  the  transfer  of  engineering  data  to 
manufacturing.  Electronic  mail  has  a  size  limit  of  one  to  two  megabytes.  Therefore,  EDI 
will  be  used  to  move  large  files.  A  translation  system  will  make  application-to-application 
communication  possible.  A  process  model  for  the  approval  process  is  proposed.  Data  will 
reside  in  a  data  warehouse  or  knowledge  repository.  The  entire  system  will  move  from  a 
mainframe  to  smaller  computers. 

The  Motorola  Corporate  vision  is  a  “wall-less  work  space”  where  desk-to-desk  vid¬ 
eo  conferencing  and  co-development  among  engineers  is  supported.  It  is  moving  toward 
this  vision  of  enterprise  integration  with  a  five-year  plan. 

The  Corporate  view  of  information  conununication  is  a  global  one  that  includes 
vendors  and  suppliers.  The  exact  percentage  of  its  parts  that  are  outsourced  was  not  speci¬ 
fied,  but  80%  of  those  parts  are  produced  by  20%  of  its  vendors.  Motorola  wants  to  estab¬ 
lish  lifetime  relationships  with  its  vendors.  This  relationship  includes  the  extension  of  the 
Corporate  philosophy  of  Six  Sigma  quality  goals  to  include  the  vendors.  Motorola  out¬ 
sources  primarily  for  production  rather  than  for  engineering  work. 

The  enterprise  integration  strategy  at  Motorola  Corporate  Headquarters  is  to  pro¬ 
vide  corporate  leadership  in  the  form  of  a  seven-member  team  to  coordinate  information 
sharing.  The  view  is  that  Motorola  Corporate  Staff  can  not  afford  to  do  small  projects,  that 
it  must  leverage  off  existing  work  and  undertake  major  projects.  However,  this  perception 
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is  not  supported  by  the  cunent  approach  to  integration.  For  example,  the  four  small  COF 
projects  would  appear  to  contradict  this. 

Information  Infrastructures: 

The  enterprise  integration  work  is  process  model  based.  Tables  are  used  to  drive 
the  code.  Motorola  has  incorporated  an  object-oriented  paradigm  due  to  a  belief  that  it  will 
support  change  more  readily.  Unfortunately,  the  code  being  developed  by  subcontractors 
and  consultants  embeds  the  model  and  will  be  expensive  to  change  should  the  model 
change 

Motorola  is  running  many  different  CAD  systems,  primarily  due  to  the  different 
platforms  they  support  A  data  warehouse  is  used  by  engineers  and  management  currently. 
EDI  is  supported. 
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MOTOROLA  PAGING  PRODUCTS  GROUP 


Dc&  Iption  of  the  Business: 

This  division  of  Motorola  designs  and  manufactures  a  line  of  pager  devices. 

Industry  1991: 

State  of  Int^ration: 

Management  at  Motorola  Paging  Products  Group  of  the  Motorola  Paging  Division 
(MPD)  believes  that  enterprise  integration  will  support  its  goal  of  Six  Sigma  Quality.  Inte¬ 
gration  has  allowed  them  to  begin  tracking  errors  using  bar  codes.  Thus,  they  have  elimi¬ 
nated  some  of  the  paper  previously  associated  with  the  manufacturing  process.  Information 
integration  now  supports  a  more  advanced  approach  to  controlling  the  production  process. 
The  goal  is  total  defect  elimination  in  all  its  factory  and  office  processes.  Shipping,  order¬ 
ing,  manufacturing,  and  invoicing  are  all  included  in  the  integrated  process  plan.  Motorola 
Paging  Products  Group  is  asking  its  preferred  suppliers  to  make  a  commitment  to  quality 
and  cycle  time  performance  to  support  their  objectives. 

The  Bandit  product  line  was  started  six  years  ago.  Speedy  is  a  rebirth  of  Bandit.  On 
the  Speedy  product  line,  a  significant  amount  of  software,  hardware,  and  people  were 
reused,  resulting  in  a  very  steep  learning  curve.  Significant  decreases  in  the  cycle  time  were 
achieved. 

Some  suppliers  have  been  included  with  EDI.  This  is  a  test  program,  however. 
Some  customers  who  provide  a  substantial  volume  are  connected  on-line  with  systems  in- 
house  for  direct  order  capability. 

EDI  is  critical  to  strengthen  U.S.  industry.  The  EDI  effort  at  Motorola  Paging  Prod¬ 
ucts  Group  is  on  schedule.  MPD  purchases  a  service  fi'om  GE  to  translate  EDI  between 
Motorola  Paging  Products  Group  and  its  suppliers. 

Currently  all  the  divisions  contribute  to  “schedule  sharing.”  In  this  system,  elec¬ 
tronic  schedules  are  passed  up  to  corporate.  The  schedule  is  very  detailed,  including  infor¬ 
mation  to  the  supplier  level.  Schedule  sharing  gives  you  an  average  schedule.  Some 
suppliers  however  prefer  exact  MRP  data.  The  system  gh  es  suppliers  26-week  visibility 
on  orders. 
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Integration  Strategies: 

The  ultimate  goal  at  Motorola  Paging  Products  Group  is  to  be  able  to  build  any 
product  on  any  line.  Integrating  design  with  CIM  is  currently  the  weakest  link  at  MPD. 
They  are  hoping  to  integrate  these  two  areas  within  one  year. 

In  a  move  toward  enterprise  integration,  the  Management  of  Information  Systems 
(MIS)  and  Software  Engineering  (SE)  groups  were  combined.  Previously,  MIS  had  provid¬ 
ed  the  business  system  support,  and  SE  had  provided  the  software  tools  and  support.  Enter¬ 
prise  integration  would  require  a  significant  amount  of  new  software  bridging  existing 
applications,  replacing  existing  applications  and  adding  new  ones.  The  expertise  of  both 
groups  would  be  needed.  This  reorganization  created  a  culture  clash  that  eventually  sorted 
itself  out  primarily  through  attrition. 

Motorola  Paging  Products  Group  places  a  great  emphasis  on  partnerships  with  sup¬ 
pliers.  A  goal  of  a  50%  decrease  in  the  supplier  base  was  set  in  1987.  The  Group  would  like 
to  receive  daily  shipments  from  the  suppliers.  The  factory  currently  runs  at  seven  turns  per 
year.  The  goal  is  30  turns  per  year. 

Two  engineers  are  currently  assigned  to  coordinate  with  the  suppliers.  Eventually, 
the  goal  is  to  co-locate  people. — that  is,  a  supplier  on  site  or  an  MPD  engineer  at  the  sup¬ 
plier  site. 

CIM  data  is  collected  and  used  on  the  production  line.  The  philosophy  is  that  only 
“useful,  timely”  data  be  available  on  the  factory  floor.  Not  necessarily  all  data  is  useful  in 
real  time.  Statistical  Process  Control  (SPC)  data  is  on  line  and  available  in  real-time. 

Wananty  data  comes  in  every  two  weeks.  It  is  provided  to  engineering  and  is  cou¬ 
pled  to  defects  per  unit  (DPU)  data.  Engineering  and  manufacturing  would  prefer  to  simply 
use  DPU;  however,  several  types  of  errors  would  not  be  caught  this  way. 

Information  Infrastructure: 

All  integration  applications  are  built  in-house.  Integrating  commercial-off-the-shelf 
(COTS)  products  is  seen  as  too  expensive  and  too  much  work.  However,  statistical  analysis 
tools  have  been  bought  and  are  now  being  integrated. 

MRP  still  exists  in  a  legacy  database  at  Motorola  Paging  Products  Group.  It  will 
phase  out  legacy  databases  by  migrating  to  a  new  relational  database  over  time. 
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Industry  2001: 

Issues  and  Barriers: 

Every  product  off  the  production  line  is  unique.  This  presents  unique  problems  for 
automation  and  information  integration.  In  addition,  some  customers  change  the  informa¬ 
tion  provided  to  Motorola  Paging  Division,  such  as  the  order,  ship  date,  or  ship  location, 
frequently  and  often  at  the  last  minute. 

Managers  at  the  MPD  do  not  see  technology  as  the  barrier  to  enterprise  integration. 
The  barrier  is  the  lack  of  widely  accepted  standards  around  which  to  architect  their  systems. 
As  a  customer,  they  feel  it  is  difficult  to  pressure  vendors  to  provide  the  right  products. 

A  high-level  visionary  within  Motorola  presented  the  goal  of  a  lights-out  factory  to 
the  CEO.  The  company  tried  it.  That  experience  has  taught  it  a  great  deal.  For  the  current 
information  integration  effort.  Motorola  did  not  begin  with  a  lengthy  statistics  collection 
process.  The  feeling  was  that  you  never  know  enough  up  front  to  justify  a  goal  or  vision  of 
the  future,  so  you  must  just  proceed. 

Motorola  has  a  Model  Factory  Project.  It  came  out  of  the  CEO  office  at  Corporate. 
Cooperation  would  increase  as  a  result.  However,  Corporate  sees  autonomous  divisions  as 
being  important  entrepreneurs  and  has  not  pushed  this  concept. 

Cultural  resistance  to  enterprise  integration  was  great  at  first.  The  pockets  of  resis¬ 
tance  changed  as  the  integration  process  has  progressed.  The  goal  is  to  simplify,  automate, 
and  decrease  costs,  using  the  savings  to  push  the  process  forward. 

Motorola  Paging  Products  Group  does  technology  roadmaps  to  monitor  emerging 
technologies.  This  should  enhance  the  results  of  an  integration  effort. 
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NATIONAL  SEMICONDUCTOR 


Description  of  the  Business: 

National  Semiconductor  designs,  manufactures,  and  markets  high-performance 
semiconductor  products.  Headquartered  in  Santa  Clara,  California,  the  company’s  major 
market  focuses  include  analog-intensive  and  communication-intensive  products. 

Industry  1991: 

Business  Strategy: 

National  Semiconductor  has  instituted  a  restructuring  plan  that  will  allow  the  com¬ 
pany  to  consolidate  its  underutilized  manufacturing  capacity  while  it  upgrades  its  continu¬ 
ing  operations  and  improves  their  utilization.  These  changes  are  beginning  to  have  an 
effect.  The  company  anticipates  relatively  slow  revenue  growth  over  the  next  few  years,  but 
sees  fiuther  operating  advances  helping  to  build  a  lean  manufacturing  base. 

National  Semiconductor’s  investment  plans  include  investing  in  technologies  and 
tools  that  will  support  its  enterprise  integration  efforts.  In  the  resulting  environment,  trans¬ 
action-based  activities  will  be  highly  automated  (almost  rule  based).  National  Semiconduc¬ 
tor  hopes  to  decrease  costs  and  increase  productivity  by  automating  the  mechanics  of  doing 
business  and  simplifying  the  strategic  controls  of  the  business. 

Service  objectives  are  the  primary  goal  of  National  Semiconductor.  The  motto  is 
“service  second  to  none,”  National  Semiconductor  wants  to  provide  on-line,  real-time 
delivery  schedules.  The  goal  is  not  an  manufacturing  resource  planning  (MRP)  approach 
but  rather  to  monitor  the  process  in  real-time,  with  re-planning  done  every  day. 

State  of  Integration: 

In  1984  service  problems  peaked,  and  management  information  system  (MIS)  was 
not  perceived  as  part  of  the  solution.  Representatives  from  MIS  met  with  Planning  to  con¬ 
vince  them  that  MIS  would  improve  the  service  level.  WTith  focus  from  the  Director  level, 
a  cross-functional  group  was  assembled  to  implement  the  plan. 

Tlie  ASPC  project  (Automated  Semiconductor  Planning  and  Control  System)  rep¬ 
resents  an  effort  to  improve  the  planning  phase  of  the  chip  manufacturing  process.  The  goal 
is  to  optimize  the  manufacturing  schedule  based  on  major  order  placement.  The  schedule 
would  be  confirmed  continuously.  The  foundation  of  the  system  is  implemented. 
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About  7%  of  the  items  in  their  inventory  are  currently  automatically  scheduled  for 
loading  to  the  factory  floor.  Fifty  percent  of  the  components  in  special  products  are  auto¬ 
matically  loaded  to  the  factory  floor.  By  doing  automated  factory  loading,  costs  are 
decreased. 

The  normal  cycle  time  for  a  product  is  26  weeks.  This  includes  wafer  fabrication, 
electrical  test,  sort,  assembly,  and  final  test.  However,  the  assembly  and  final  test  are  con¬ 
ducted  in  southeast  Asia.  A  major  management  review  of  the  process  flow  of  24  chips  led 
to  a  20  to  30%  reduction  in  cycle  time. 

Automation  and  integration  of  manufacturing  processes  requires  predictability.  The 
fabrication  and  son  phases  of  the  process  are  never  predictable,  but  the  assembly  and  test 
portions  are.  Therefore,  the  assembly  and  test  phases  are  currently  integrated.  The  fabrica¬ 
tion  and  sort  phases  are  only  in  the  very  early  stages  of  automation.  This  integration  effort 
is  succeeding  due  to  a  high-level  champion.  Success  of  this  project  has  meant  having  to 
align  the  factory  CIM  (computer-integrated  manufacturing)  goals  with  the  rest  of  the  com¬ 
pany. 

ASPC  2.0  has  continued  to  build  on  the  initial  results  of  the  ASPC  project  Upper 
management  was  committed  to  the  effort.  The  engineering  level  and  operations  in  the  fac¬ 
tory  were  working  the  problem.  However,  the  middle  managers  saw  themselves  as  being 
“challenged.”  Their  goals  needed  to  be  realigned  and  their  jobs  changed  to  make  the  project 
successful.  Planning  against  future  resources  was  automated.  In  the  pilot  implementation, 
this  resulted  in  seven  million  pre-planned  resources,  with  1,000  manufacturing  orders,  two 
million  die  starts,  and  on-time  performance  of  98%  (and  100%  for  target  accounts).  On- 
time  performance  was  80  to  85%  before  the  implementation  of  the  system.  Previously, 
material  was  loaded  to  the  factory  two  weeks  too  early,  resulting  in  an  inventory  build-up. 
Now  even  loading  occurs.  Early  loading  can  be  planned,  however,  on  specific  orders  when 
this  is  desirable. 

The  process  of  planning  and  scheduling  the  orders  at  the  factory  is  unpopular  for 
automation.  There  is  concern  that  inventory  will  build  up.  Instead,  the  preferred  approach 
is  to  dump  the  automated  order  data  to  a  report  and  get  a  human  in  the  loop  to  review  the 
report  and  tweak  the  factory  by  placing  orders  manually.  This  manual  ordering  was  found 
to  have  only  a  slight  negative  effect  on  automated  ordering. 

PDS  (Product  Definition  System)  is  a  Bill  of  Materials  (BOM)  for  parts  produced 
at  National  Semiconductor.  PDS  supplies  an  assembly  document  and  a  routing  structure 
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which  describes  the  set  of  manufacturing  steps  for  each  part.  One  of  the  problems  encoun¬ 
tered  at  National  Semiconductor  was  a  lack  of  a  common  nomenclature  for  the  parts  pro¬ 
duced. 

Integration  Strategies: 

There  is  a  corporate  strategy  and  consensus  on  the  systems  integration  element  of 
the  enterprise  integration  process.  Initially,  the  not  invented  here  (NIH)  syndrome  was 
strong.  The  mechanism  found  to  succeed  is  to  engage  the  assistance  of  a  power  champion. 
Corporate  culture  is  changing,  requiring  many  of  the  same  changes  that  are  required  for  the 
Non-Stop  Quality  effort.  The  goal  is  to  drive  power  and  decision  making  down  in  the  cor¬ 
poration.  The  business  group  presidents  are  driving  the  effort.  The  executive  vice  presi¬ 
dents  own  the  major  processes.  In  some  cases  time-to-market  has  been  reduced  from  two 
years  to  nine  months. 

National  Semiconductor  sees  a  management  commitment  and  alignment  of  goals 
and  objectives  as  being  critical  to  project  success.  Upper  management  support  is  required 
to  implement  change. 

It  sees  major  changes  required  in  communications,  data  management,  processes, 
metrics  gathering,  and  implementation  activities  to  achieve  enterprise  integration. 

Sales  and  marketing  integration  is  driven  by  corporate-level  customer  service.  Plan¬ 
ning  integration  is  driven  by  the  head  of  Planning  (via  APCS  with  PDS).  Factory  integra¬ 
tion  is  driven  by  the  Vice  President  of  Manufacturing.  In  some  cases  the  changes  have  been 
motivated  by  quantitative  goals,  but  in  other  cases  they  have  been  motivated  by  intuitive 
appeal. 

National  Semiconductor  produces  parts  that  are  more  complex  than  parts  produced 
for  the  commercial  sector.  Further,  the  processes  involved  in  manufacturing  these  parts  are 
slightly  different 

Information  Infrastructure: 

National  Semiconductor  is  currently  using  CVS  (Central  Version  System)  which 
runs  IDMS.  )^th  the  acquisition  of  Fairchild  Semiconductor,  there  are  legacy  systems  that 
will  have  to  be  addressed  during  the  integration  of  the  enterprise. 

National  Semiconductor  is  on  the  American  National  Standards  Institute  Electronic 
Data  Interchange  (ANSI  EDI)  committee.  Sixty  to  seventy  percent  of  its  orders  come  in 
EDI. 
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Industry  2001: 

Issues  and  Barriers: 

A  unique  problem  facing  National  Semiconductor  is  the  world-wide  factory  distri¬ 
bution  problem.  National  Semiconductor  must  have  a  “cutoff’  to  synchronize  the  factories 
around  the  world.  It  must  get  the  other  factories  to  stop  at  the  end  of  a  Califomi.^  workday 
to  do  backups  and  synchronize  planning  for  the  next  day. 
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E.10  NeXT  COMPUTER,  INC. 


Description  of  the  Business: 

Designs  and  manufactures  workstations  and  their  operating  and  application  soft¬ 
ware. 

Industry  1991: 

Business  Strategy: 

NeXT  Computer,  Inc.,  believes  that  the  cost  drivers  in  the  workstation  market  are 
time-to-market,  quality,  and  flexibility.  U  has  placed  greater  emphasis  on  optimizing  these 
factors  throughout  its  organization.  However,  automated  manufacturing  was  identified  as 
playing  a  key  role  in  achieving  a  competitive  advantage. 

In  examining  the  manufacturing  phase  of  the  product  development  cycle,  NeXT 
estimated  that  offshore  manufacturing  causes  a  three-  to  six-month  delay  in  time-to-market. 
To  eliminate  this  delay,  NeXT  built  its  manufacturing  facility  next  to  the  research  and 
development  (R&D)  center. 

A  strong  emphasis  was  placed  on  retaining  highly  qualified  workers.  As  a  result, 
70%  of  NeXT  CIM  (computer-integrated  manufacturing)  and  management  staff  have 
advanced  degrees.  Increased  factory  floor  automation  has  meant  that  fewer  people  are 
required  to  run  the  production  line.  Currently  six  to  eight  people  run  the  entire  line.  The 
eventual  goal  is  two  shifts  (12  to  14  people).  These  individuals  are  fully  cross-trained  to 
operate  other  stations  on  the  line. 

State  of  Integration: 

NeXT  currently  supports  integrated  manufacturing.  It  operates  a  continuous  manu¬ 
facturing  process.  That  is.,  once  manufacturing  starts  and  parts  go  down  the  line,  the  pro¬ 
duction  line  is  not  stopped.  It  cuirently  takes  20  minutes  to  build  a  board  with 
approximately  1,400  to  1,500  components  on  the  line.  It  takes  one  hour  to  build  the  entire 
workstation  product. 

Board  assembly  defect  rates  are  very  low  due  to  continuous  process  control.  At  one 
competitor  the  yield  or  surface  mount  defect  rate  is  800  per  million.  At  NeXT  the  yield  is 
40  per  million. 
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Inventory  storage  and  transportation  costs  can  be  high.  This  fact  motivates  NeXT 
to  maintain  an  exceptionally  low  inventory.  The  manufacturing  facility  then  serves  as  the 
warehouse  for  the  inventory. 

As  an  example  of  the  success  of  this  approach  to  product  development,  Next  was 
able  to  go  from  concept  to  shipping  in  1 1  months,  beating  the  next  best  competitor  by  5 
months. 

NeXT  believes  that  enterprise  integration  provides  significant  savings  over  the  typ¬ 
ical  “islands  of  automation”  approach  to  product  development.  NeXT  projects  a  factor  of 
15  to  20  improvement  in  productivity,  measured  in  sales  per  manufacturing  touch  labor, 
versus  the  benchmark  of  a  typical  manufacturer. 

Integration  Strategies: 

NeXT  developed  a  strategy  for  CIM  by  surveying  the  leading  domestic  electronic 
and  computer  manufacturers.  The  strategy  was  based  on  the  following; 

♦  Strive  for  a  single-layer  architecture. 

♦  Create  object-oriented  software  tools  to  eliminate  non-value-added  CIM  work. 

♦  Develop  quality  control  systems  based  on  real-time  access  to  all  data. 

NeXT  stresses  flexibility.  Hardware  designers  participate  during  manufacturing 
start-up.  They  observe  and  participate  in  tweaking  the  process.  Manufacturing  engineers 
provide  feedback  to  design  engineers  on  manufacturability  and  part  reliability  and  avail¬ 
ability. 

One  strategy  that  NeXT  uses  to  ensure  manufacturability  is  an  “approved  parts  list.” 
Designers  select  from  that  list  to  assure  quality,  reliability,  and  that  the  package  is  consistent 
with  the  manufacturing  process.  Manufacturing  is  responsible  for  developing  the  parts  list, 
based  on  knowledge  from  the  factory  floor.  Manufacturing  also  monitors  designs  for  com¬ 
pliance.  During  the  design  of  the  first  product,  manufacturing  vetoed  35  components  select¬ 
ed  by  designers. 

Rapid  prototyping  is  done  on  the  factory  floor  using  the  production  line  rather  than 
in  a  lab.  Thus,  R&D  must  come  to  the  factory  to  watch  the  design  being  built.  In  this  way 
design  engineers  work  with  manufacturing  engineers  to  develop  the  product  and  the  man¬ 
ufacturing  process. 
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Information  Infrastructure: 

All  corporate  information,  including  inventory,  orders,  and  manufacturing  and 
i  design  data,  is  integrated  and  available  world-wide  to  any  user  on  any  computer.  The  data 

may  take  the  form  of  text,  graphics,  audio,  or  applications. 

A  heterogenous  mix  of  systems  has  been  integrated  where  appropriate.  The  man¬ 
agement  information  system  (MIS)  databases  are  hosted  on  a  Sequent  Unix-based  machine 
®  that  is  optimized  for  database  transactions.  Printed  circuit  boards  (PCB)  computer-aided 

design  (CAD)  is  done  on  Apollo  workstations.  Mechanical  CAD  is  done  on  Hewlett-Pack¬ 
ard  (HP)  workstations.  The  CIM  users  work  from  NeXT  workstations. 

^  NeXT  uses  a  CAD  system  for  not  only  design  but  also  to  control  and  program  the 

factory  robots.  An  example  of  the  integration  between  R&D  and  manufacturing,  an  appli¬ 
cation  called  MENTRANS  (MENTOR  CAD  Translator),  is  used  to  convert  PCB  files  on  a 
CAD  system  to  optimized  programs  for  the  inspection  and  pick-and-place  machines  on  the 
^  manufacturing  floor.  This  application  can  convert  a  one  megabyte  file  of  CAD  data  to  a 

machine  program  in  a  few  seconds.  The  programs  are  then  optirtuzed  for  placement  cycle 
time  and  machine  wear  within  three  or  four  minutes. 
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E.11  TEKTRONIX,  INC. 


Description  of  the  Business: 

Tektronix,  Inc.,  initially  established  its  reputation  in  oscilloscopes.  The  company 
diversified  into  new  products  and  markets  in  the  early  1 970s.  Today,  Tektronix  has  three 
primary  product  categories;  Test  &  Measurement,  Television  Systems,  and  Computer 
Graphics. 

Industry  1991: 

State  of  Integration: 

About  10  years  ago  a  study  was  done  of  the  product  design  processes  of  Tek’s  cus¬ 
tomers.  The  goal  was  to  understand  an  expanded  role  for  oscilloscopes  in  computer  engi¬ 
neering.  The  surprising  conclusion  was  that  the  computer  companies  were  more  integrated 
than  Tektronix  in  their  own  engineering  and  manufacturing.  Momentum  for  the  CAX  Cen¬ 
ter  emerged  from  the  study  (CAX  =  Computer  Aided  everything,  X  is  a  variable). 

Tek’s  strategy  has  been  to  replace  paper  transfer  with  translators  and  electronic  file 
transfer.  In  the  past  each  Division  or  Group  has  made  its  own  acquisition  decisions  and 
there  was  a  tremendous  diversity  of  adoptions.  The  CAX  Center  has  built  translators  and 
so  forth  to  enable  integration  with  multiple  diverse  tools.  The  first  level  of  integration  is 
represented  by  the  following  stream  model  for  mechanical  design  (Figure  E-2). 

design  - ►  analysis  - ►  tooling  - ►  NC 

t _ I 


Figure  E>2.  Mechanical  Design  Stream  Model 

Tektronix  is  at  this  level  of  integration  today  in  all  disciplines.  The  same  stream 
model  exists  for  each  discipline  (mechanical,  documentation,  software,  circuit,  printed  cir¬ 
cuit  board  (PCB)),  but  there  is  very  little  crosstalk  between  the  disciplines.  PCB  has  both 
geometry  and  electrical,  and  it  transfers  geometry  via  IGES  (Initial  Graphics  Exchange 
Specification).  Documentation  is  the  biggest  opportunity  for  crosstalk,  and  it  may  succeed 
because  of  the  CALS  (Computer-Aided  Acquisition  and  Logistics  Support)  model. 

The  Mechanical  Computer-Aided  Engineering  (MCAE)  program  integrated  the 
MCAE  tools  with  the  model  shops,  largely  by  replacing  paper  drawings  with  electronic 
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drawings  and  automating  prototyping  operations.  The  program  reduced  cycle  time  from 
design  to  prototype  with  no  increased  operating  expense. 

The  Computer-Aided  Design  -  Computer-Aided  Manufacturing  (CAD-CAM)  Link 
deals  with  PCB  design  translations.  There  is  potentially  a  sequence  of  target  machines,  for 
example,  depending  on  whether  the  PCB  is  through  hole  or  surface  mount,  or  because  spe¬ 
cific  component  part  numbers  may  be  allocated  to  specific  machines.  In  addition,  the  com¬ 
ponent  insertion  sequence  (the  snake  path)  must  be  prepared  for  each  board.  This  was  first 
automated  with  a  point-and-click  interface,  but  now  it  is  algorithmic. 

The  system  uses  an  intermediate  format  with  one  translator  from  each  PCB  design 
system  to  the  intermediate  format  and  one  translator  from  the  intermediate  format  to  each 
type  of  NC  (numerical  control)  machine.  The  system  also  deals  with  documentation  and  a 
color  report  display  for  operators.  In  a  procedural,  operational  system,  the  human  aspect 
must  be  tended  to. 

The  Engineering  Master  System  stores  the  parts  information,  including  geometry  of 
footprints,  for  all  Tek  parts.  The  master  copy  of  the  parts  database  is  kept  in  a  relational 
database  in  the  CAX  center.  ASCII  files  containing  the  data  are  exported  to  every  Division 
within  the  company.  Every  day  that  there  is  a  change  or  addition  to  the  database,  new  ASCD 
files  are  downloaded  automatically  overnight.  ASCII  is  the  exported  form  because  it  retains 
the  file  format  of  the  predecessor  legacy  system.  Some  groups  now  re-import  the  ASCII 
data  into  relational  databases  of  their  own,  such  as  SQL/DB  and  FoxBase. 

The  Test  and  Measurement  Documentation  system  does  printing  on  demand  for  all 
manuals.  The  manual  set  to  accompany  an  order  is  printed  from  the  order’s  BOM  (bill  of 
materials)  by  selecting  chapters  that  reflect  exactly  the  options  ordered.  Printing  the  parts 
catalogue  extracts  data  from  databases  so  that  each  time  a  catalogue  is  printed,  it  is  “auto¬ 
matically”  up  to  date. 

Engineering  Change  Order  (ECO)  processing  and  support  are  divisionalized.  The 
ECO  process  is  relatively  paper  based.  There  is  an  Interleaf  add-on  that  writes  into  the  ECO 
database  when  an  ECO  document  is  created. 

At  one  time  there  existed  a  Reliability  Information  Systems  Group.  Failing  boards 
were  shipped  to  the  central  board  repair  facility  and  records  of  component  failure  were 
placed  into  a  database.  The  Field  Service  Operation  was  one  of  the  last  to  be  divisionalized. 
The  reliability  database  was  sliced  up.  Some  data  was  transferred  to  the  Test  &  Measure¬ 
ment  Group,  and  some  was  lost 


Integration  Strategies: 

Tektronix  is  poised  to  adopt  common  CAD/CAM  throughout  the  corporation.  It 
will  adopt  a  single  system  for  each  of  PCB,  CAM,  Software  Engineering,  Technical  Doc¬ 
umentation,  and  Product  Data  Management. 

The  initiative  is  coming  from  the  CEO  who  feels  that  the  benefits  of  uniform  tools, 
including  reduced  training  and  support  expenses,  outweigh  the  costs  of  displacing  legacy 
systems. 

Common  platforms  and  tools  ease  integration.  Tek  is  going  to  pick  one  preferred 
platform,  or  at  least  one  for  each  discipline.  Sun  is  preferred  for  CASE  (computer-aided 
software  engineering).  Tek  will  select  a  few  preferred  vendors,  striving  to  minimize  porting 
and  diversity  overhead.  Tek  will  standardize  on  one  operating  system  and  on  one  interface 
(X  windows). 

The  current  stream  integration  model  will  be  superceded.  The  second  level  of  inte¬ 
gration  is  to  establish  a  common  database  used  by  all  tools  in  a  design  discipline  (Figure  E- 
3): 


Figure  E<3.  Common  Database 

The  database  would  provide  multiple  views  of  the  data  including  shadowed  data, 
hidden  data,  and  orthographic  data. 

For  legacy  systems,  Tek  is  following  a  displacement  strategy.  It  is  being  done  on  a 
product  line  by  product  line  basis  to  avoid  using  both  a  legacy  system  and  a  new  system  in 
a  single  product,  thus  minimizing  the  integration  problem.  To  satisfy  maintainability 
requirements,  Tek  will  keep  “one  of’  each  legacy  system  in  the  CAX  center  or  in  the  using 
division. 


( 
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The  Engineering  Master  System  will  be  replaced  by  a  data  warehouse.  Tek  will  con¬ 
vert  the  parts  data  first  and  then  build  a  catalog  system. 

Information  Infrastructure: 

A  coherent  network  is  helpful.  Tek  uses  TCPAP  (Transmission  Control  Protocol/ 
Internet  Protocol)  and  DECNet;  the  IBM  mainframe  is  the  last  bastion  of  hard-to-access 
data. 

Tek  uses  relational  databases  although  they  are  less  used  than  they  could  be.  The 
databases  used  in  the  company  for  product  information  range  from  Paradox  DB  on  personal 
computers  to  SQL/DB  on  the  IBM  mainframe. 

Standard  formats  are  needed.  IGES  is  used  in  mechanical,  from  design  to  fab.  IGES 
cannot  transfer  100%  of  the  design  data,  but  the  important  stuff  gets  through. 

For  the  CAD-CAM  Link,  Tek  chose  to  use  Mitron’s  BDF  (Integrated  Data  Format) 
as  a  neutral  drafting  format  The  IDF  data  only  contains  connectivity  and  XY  placement 
information.  The  geometry  for  parts  is  added  from  the  parts  database. 

Lessons  Learned: 

Top-down  sponsorship  is  needed  to  succeed;  otherwise  there  is  too  much  resistance 
at  the  operational  level. 

In  the  mid-1980s  there  existed  about  a  half-dozen  little  integration  groups  in  Divi¬ 
sions.  After  two  or  three  years  those  groups  didn’t  persist  (due  to  budget  reductions  or  per¬ 
sonnel  transfers).  \V^thout  support,  the  systems  disappeared.  This  approach  was  not  general 
enough.  The  CAX  Center  has  prospered  because  it  was  a  general  corporate  approach  to  the 
problem  with  continuity  of  personnel  and  management  support. 

Tool  specialists  are  needed  to  do  integration  and  tool  support  staff.  The  support  per¬ 
son  provides  the  user  point-of-view  and  feedback.  This  make  a  good  combination  and  has 
been  highly  productive. 

The  availability  of  formats  from  CAD  vendors  (whether  supported  standards  or 
open  proprietary  formats)  eases  integration.  Data  from  the  successful  CAD  companies  are 
more  available  than  the  data  from  the  less  successful  companies. 

It  is  crucial  to  train  and/or  recruit  local  people  (in  the  operating  divisions)  to  support 
the  integrated  system.  When  installed  where  there  were  zero  local  owners,  problems 
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occurred  and  band-aids  were  needed.  When  installed  where  there  were  at  least  two  local 
owners,  there  was  always  a  success  story 

Regarding  object-oriented  technology;  object-oriented  databases  do  not  have  a 
common  data  model  (as  relational  systems  do).  Tek  has  used  Smalltalk  internally  to  devel¬ 
op  some  analog  tools.  They  were  developed  very  fast  and  have  acceptable  performance. 

There  were  some  integrity  problems  with  the  Engineering  Master  System  in  the 
past.  One  problem  was  the  lack  of  common  spelling  for  certain  attribute  values.  Originally 
the  attributes  were  character  strings.  One  problem  was  that  values  would  be  entered  with 
spelling  or  typing  errors  and  would  not  match  correct  retrieval  keys.  Another  problem  was 
that  incorrect  values  would  be  entered.  The  solution  was  to  replace  strings  with  enumerated 
attributes  (such  as  enum  RAM,  ROM,  etc.).  This  ensured  that  values  were  valid  members  of 
the  domain  into  which  they  were  being  entered  since  only  identifiers  in  the  enumerated  list 
were  accepted.  However,  there  is  a  need  for  parametric  attributes  (e.g.,  8-bit,  16-bit,  32-bit 
BUS,  or  1  Mbyte,  4  Mbyte,  or  16  Mbyte  RAM).  The  enum  work  has  not  been  extended  to 
parametric  attributes. 

Industry  2001: 

Future  Information  Infrastructure: 

TV  products  have  so  many  options  that  each  product  is  almost  a  custom  product. 
Tek  is  developing  a  downstream  tracking  system  by  serial  number  that  will  reflect  the  as- 
built  configuration  of  each  unit.  This  future  system  will  support  field  maintenance  by  giving 
module  replacement  compatibility  with  new  modules. 
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E.12  TEXAS  INSTRUMENTS  (Tl) 

Description  of  the  Business: 

Designer  and  manufacturer  of  semiconductor  products  and  devices  using  those 
products. 

Industry  1991: 

Business  Strategy: 

TI  used  a  combination  of  various  business  case  justifications  for  its  enterprise  inte¬ 
gration  plan.  These  justifications  included  cost-benefit  analyses  and  an  approximate  retum- 
on-investment  (ROI)  calculation.  Changing  to  a  client  server  model  will  be  critical  in  driv¬ 
ing  down  business  costs.  The  percentage  of  expenditures  required  to  provide  services 
drives  the  business  case  for  enterprise  integration.  Tl  will  attempt  to  merge  this  with  infor¬ 
mation  on  technology  costs.  But  managers  at  Texas  Instruments  acknowledge  that  these 
analyses  were  not  rigorous  and  that  the  justification  was  based  at  least  partially  on  intuition 
and  gut  level  feeling  that  enterprise  integration  was  the  right  thing  to  do. 

State  of  Integration: 

The  Information  Systems  and  Services  Group  within  the  Information  Technology 
group  has  been  responsible  for  centralizing  corporate-level  services  like  electronic  mail. 
The  electronic  mail  system  uses  X.400  to  provide  external  connectivity  and  handles 
250,000  messages  per  day. 

Information  Engineering  Facility  (lEF)  is  oeing  used  for  business  applications.  It  is 
a  fully  integrated  computer-aided  software  engineering  (CASE)  tool  based  on  the  James 
Martin  methodology.The  premise  is  Uiat  all  the  information  generated  in  the  life  cycle  of  a 
product  will  be  maintained  in  the  lEF  Encyclopedia.  lEF  provides  several  integrated  tools 
including  the  following: 

•  Planning  Toolset  for  top-level  managers 

•  Analysis  Toolset  for  end-users 

•  Design  Toolset  for  end-users  and  data  processing  professionals 

•  Constmetion  Toolset  that  produces  machine  code 

lEF  runs  DB2  -based  business  applications.  Interfacing  with  non-DB2  applications 
is  difficult.  The  goal  is  for  Texas  Instruments  to  increase  the  number  of  business  applica¬ 
tions  on  lEF  from  9  to  60%.  The  plans  do  not  call  for  TI  to  move  away  firom  the  information 
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management  system  (IMS)  completely,  and  to  support  an  object-oriented  environment  with 
lEF  in  five  years. 

Currently,  electronic  data  interchange  (EDI)  occurs  with  approximately  40  to  50% 
of  the  customers  for  the  semiconductor  group.  All  the  electronic  order  and  payment  infor¬ 
mation  migrates  to  a  mainframe.  A  human  picks  up  the  order  information  and  plans  and 
schedules  the  manufacture  of  the  product.  Currently,  some  information  must  be  manually 
re-entered.  TI  recognizes  that  these  islands  of  automation  are  inefficient  and  costly. 

TI  is  working  on  just-in-time  (JIT)  delivery  from  suppliers.  The  enterprise  integra¬ 
tion  plan  includes  JIT  for  their  production  lines. 

TI  has  an  electronic  payment  scenario  using  DECASS. 

TI  is  trying  to  develop  a  programmable  factory.  Today,  almost  no  process  control  is 
done.  Operators  are  not  trained  how  to  use  the  data  from  the  machines  for  Statistical  Pro¬ 
cess  Control  (SPC).  Only  after  the  fact  analysis  is  done.  One  problem  is  that  multiple  trans¬ 
lations  are  required  due  to  the  use  of  mainframes,  operator  consoles,  and  machine 
controllers.  TI  is  working  to  implement  automatic  process  machine  control.  The  system 
will  include  a  dynamic  scheduler  that  will  monitor  work  in  progress  and  advise  the  opera¬ 
tors. 

Integration  Strategies: 

TI  has  a  goal  of  enterprise  integration  within  the  next  three  to  five  years.  The  enter¬ 
prise  integration  plans  include  transitioning  from  an  IBM  mainframe-based  Data  Vault  to  a 
client-server  architecture.  After  removing  all  local  site  mainframes,  the  business  applica¬ 
tions  will  be  hosted  on  a  “mega  center.”  All  the  sites  will  be  connected  as  clients.  TI  is  cur¬ 
rently  in  the  process  of  deciding  which  applications  will  be  located  at  the  mega  center  and 
which  will  be  located  at  client  nodes.  The  concept  of  “brilliant  machines”  where  there  is 
interaction  and  feedback  between  a  machine  and  its  schedule  is  being  pursued. 

The  Microelectronics  Science  and  Technology  (MMST)  project  will  develop  a  fac¬ 
tory  architecture  applicable  to  “mega  fabs,”  allowing  queues  of  up  to  200  lots  and  not  just 
“mini  fabs”  allowing  low-volume  ASIC  (application-specific  integrated  circuit)  produc¬ 
tion.  The  work  will  center  around  integrating  commercial  equipment,  building  only  what 
cannot  be  purchased  and  conforming  to  standards.  The  project  will  use  a  fully  distributed, 
object-oriented  database. 
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TI  is  developing  an  order  entry  system,  TIES  (Tooling  and  Information  System), 
that  will  allow  a  customer  and  mask  vendor  to  exchange  information  electronically.  This 
should  save  $380,000  in  labor  costs.  TIES  will  also  decrease  the  number  of  errors  generated 
during  order  entry.  TI  estimates  that  errors  cost  $100,000  each. 

TIES  will  include  both  IMS  and  CAD  (computer-aided  design)  data.  Until  now,  the 
trend  has  been  to  move  CAD  data  into  IMS.  However,  engineers  prefer  to  work  on  work¬ 
stations.  So  by  moving  the  CAD  data  out  of  IMS,  TI  will  eliminate  the  need  for  a  host  main¬ 
frame  computer.  The  goal  is  to  network  several  separate  systems.  TI  has  not  attempted  to 
distribute  the  database.  Instead,  a  single  centralized  database  accessible  woild-wide  will  be 
used.  This  makes  the  communication  network  critical.  This  is  still  an  area  of  concern  for 
TI.  The  Data  Archival  and  Retrieval  (DART)  component  of  TIES  will  provide  the  data  stor¬ 
age  facilities. 

TIES  will  be  implemented  in  three  phases: 

•  Phase  1  will  include  an  Oracle  database  with  DART  indexes  to  access  archival 
data.  Falcon  will  be  used  for  the  user  interface  and  data  collection. 

•  Phase  2  will  use  an  Oracle  database  for  TIES  indexes.  This  database  will  pro¬ 
vide  pointers  to  data  stored  in  DART  as  well  as  pointers  to  internal  data.  The 
DART  storage  system  and  database  will  be  used  for  all  other  data. 

•  Phase  3  will  provide  a  unified  database  with  file,  relation,  and  object-oriented 
database  capabilities  for  both  TIES  and  DART. 

Some  of  the  benefits  of  the  DART  system  include  permanent  storage  of  mask  and 
reticle  instructions  and  graphics.  The  system  will  eliminate  the  need  for  paper  processing 
and  will  help  eliminate  order  errors. 

TI  has  selected  die  Falcon  as  the  user  interface  and  for  data  collection  for  TIES.  It 
is  now  developing  a  standard  format  for  purchase  and  mask  orders.  One  benefit  of  electron¬ 
ic  order  formats  will  be  that  Japanese  customers  will  be  able  to  convert  the  information  to 
and  from  Kanji  more  readily  than  when  the  information  was  exchanged  in  paper  form.  TI 
is  now  developing  a  first  cut  at  the  user  interface  for  the  order  forms.  Eighty  percent  of  the 
orders  received  by  TI  are  simply  modifications  of  previous  orders.  One  goal  for  the  new 
system  is  introduce  the  use  of  electronic  signature  for  approval.  The  system  will  check  for 
this  electronic  sign-off  before  allowing  wafer  fabrication  to  proceed. 
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The  Product  Drawing  Control  System  (PDCS)  project  is  a  prototype  system  to  sup¬ 
port  on-line  creation,  editing,  sign-off,  and  distribution  of  engineering  drawings.  Ninety 
percent  of  the  engificcring  drawings  produced  at  H  are  in  a  CAD  system.  Over  4,000  draw¬ 
ings  exist  Thi:.  prototype  supports  Autocad,  CV,  CAD  System  Development  (a  native  CAD 
file),  and  plot  files.  However,  sign-off  still  requires  a  paper  copy.  Another  utility  allows 
engineers  to  red  line  drawings  electronically  by  annotating  plot  files.  TI  is  experimenting 
with  putting  a  plotter  and  workstation  at  subcontractor  sites  and  electronically  sharing  engi¬ 
neering  data.  Of  the  1,000  vendors  working  with  Tl,  less  than  10  vendors  currently  have 
such  a  capability  in  place.  However,  this  system  is  raising  many  issues  associated  with  hav¬ 
ing  a  softcopy  system.  For  instance,  are  the  available  personal  computer  graphics  systems 
adequate  for  inspectors  on  the  factory  floor,  and  does  the  zoom  capability  (D-size  drawings 
are  unreadable)  lose  the  context?  The  question  is,  is  PCDS  an  effective  mechanism  for 
drawing  distribution?  The  system  does  decrease  the  time  to  copy  and  the  time  to  drawing 
release. 

TI  would  like  to  provide  a  hypertext  information  system  with  archival  capabilities 
to  vendors.  Such  a  system  will  go  into  beta  test  in  March  1992. 

TI  recognizes  the  need  for  electronic  data  book  and  terminology  standards.  Suppli¬ 
ers  of  components  do  not  want  to  provide  electronic  data  files.  The  cost  is  too  high.  EDI  is 
has  become  too  expensive  because  the  workers  who  provided  the  services  pre-EDI  have 
been  retained.  Currently,  data  books  cost  $10  million  per  year  to  produce.  The  books  may 
contain  30,000  pages  and  18  different  product  families.  They  provide  software  support 
guides,  hardware  development  guides,  user  guides,  and  training  materials.  Electronic  data 
books  could  save  a  significant  amount  of  money. 

Tl  is  attempting  to  decrease  the  number  of  business  models  in  use.  It  currently  has 
between  70  and  120  models,  25  or  30  of  which  are  foundational  models.  The  goal  is  to 
reduce  the  number  to  12  to  14  models.  They  are  working  to  put  the  foundational  pieces, 
those  common  to  customers,  employees  and  the  organization,  in  place.  The  rest  of  the  sys¬ 
tem  will  be  built  on  top  of  these  pieces. 

There  are  currently  95  applications  that  assess  the  customer  IMS.  This  would  have 
required  95  models.  Instead,  a  shared  model  will  be  developed.  The  lEF  reporting  capabil¬ 
ity  has  allowed  TI  to  uncover  duplication  and  redundancies  like  this. 

Another  example  of  the  model  redundancy  is  the  part  number  system.  Several  sep¬ 
arate  systems  currently  exist  within  the  company.  By  reducing  this  to  a  single  model,  TI 
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will  also  change  the  way  it  does  business.  TI  is  seeking  to  encourage  data  stewardship  rath¬ 
er  than  data  ownership.  First- level  managers  with  profit  and  loss  responsibility  have  been 
the  most  reluctant  so  far. 

Tl  will  be  CALS  (Computer-Aided  Acquisition  and  Logistics  Support)  compliant, 
but  is  not  looking  to  be  a  leader  in  this  area.  In  the  past  Tl  has  automated  everything,  some¬ 
times  resulting  in  being  able  to  do  the  wrong  things  faster.  Now  it  is  re-engineering  process¬ 
es  before  considering  automating  them. 

Information  Infrastructure: 

An  IBM  mainframe  is  currently  used  to  control  planning,  shipping,  and  marketing 
information.  Information  about  the  fabrication  process  is  saved  in  lot  log  points  for  work 
in  progress  tracking. 

Tl  considers  frameworks  to  be  a  major  opponunity  in  integrating  the  enterprise.  The 
DART  system  has  selected  Falcon.  However,  Falcon  is  not  Motif  based.  This  conflicts  with 
other  system  decisions  that  have  been  made.  Since  Tl  has  found  it  very  difficult  to  integrate 
existing  databases,  it  requires  a  framework  that  supports  both  relational  and  object-oriented 
databases.  Further,  the  framework  must  be  platform  independent  and  snp^  )rt  X  Windows 
as  well. 

Industry  2001: 

Issues  and  Barriers: 

TI  sees  too  many  competing  standards  and  consortia  efforts.  It  is  supporting  IRDS 
(the  Information  Resource  System  Dictionary)  and  OSF  (Open  Software  Forum). 

TI  does  not  see  technology  as  being  a  barrier  to  enterprise  integration.  Rather,  the 
cultural  issues  tend  to  be  a  bigger  problem.  TI  has  typically  encouraged  individualism  and 
innovation.  Now  very  capable  engineers  are  being  asked  to  allow  someone  else  to  make 
major  decisions  regarding  how  the  new  system  will  work  and  how  the  engineers  will  do 
their  jobs.  TI  found  that  because  of  this,  developing  grass  roots  support  and  winning  over 
the  engineers  were  critical  to  the  success  of  the  integration  effort.  A  common  vision  is  nec¬ 
essary  to  arrive  at  a  solution. 

Within  TI,  individual  business  units  have  a  great  deal  of  operational  autonomy  in 
that  they  may  have  their  own  legal,  computer,  or  other  services.  Thus,  corporate  groups  pro¬ 
viding  central  services  have  to  become  the  “vendor  of  choice”  to  the  rest  of  the  company. 
This  provides  tremendous  incentives  for  optimizing  the  operation. 
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The  current  automated  environment  is  so  integrated  that  they  cannot  respond  to 
changes.  TI  management  sees  the  goal  of  decentralizing  the  topology  as  one  solution  to  this 
problem.  The  vice  president  of  the  ICS  group  is  driving  the  decentralization  effort.  This 
high-level  support  should  facilitate  and  speed  the  process. 

Technology  turnover  is  occurring  very  fast.  TI  finds  it  very  hard  to  optimize  their 
manufacturing  practices  to  any  degree.  TI  has  focused  on  developing  a  new  stable  process 
flow  for  manufacturing.  Time-to-market  (TTM)  is  critical.  Eighty  percent  of  the  profits  are 
made  in  the  first  twelve  months  a  product  is  on  the  market.  Companies  who  enter  the  market 
after  that  merely  supply  products — they  do  not  make  a  profit. 
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E.13  WESTINGHOUSE  ELECTRONIC  SYSTEMS  GROUP 
Description  of  the  Business: 

Wsstinghouse  Electric  Corporation  focuses  on  seven  basic  business  segments: 
Environmental  Systems,  The  Knoll  Group  (furniture).  Electronic  Systems,  Power  Systems, 
Industries,  Broadcasting  and  Financial  Services.  The  Electronic  Systems  Group  (ESG)  sup¬ 
plies  advanced  electronic  systems  to  the  Department  of  Defense  (DoD)  and  markets  related 
commercial  products.  ESG  products  range  from  radar  to  electric  vehicles. 

Industry  1991: 

Business  Strategy: 

ESG  is  moving  to  expand  in  commercial  markets  that  are  complementary  to  its 
defense  business  base,  markets  such  as  air  traffic  control,  home  security,  aircraft  power  gen¬ 
eration,  and  drug  traffic  interdiction.  The  defense  market  segment  will  be  flat  or  down  for 
the  first  half  of  the  1990s,  but  non-DoD  markets  are  expected  to  grow  15  to  20%  a  year. 
About  33%  of  ESG  products  are  commercial. 

Westinghouse  is  seeking  to  leverage  ManTech  and  IMIP  funding  to  achieve  a  com¬ 
puter-integrated  enterprise  (CEE).  It  is  also  trying  to  get  Westinghouse  partners  to  adopt  its 
view. 

State  of  Integration: 

An  ESG  process  model  has  been  developed.  ESG  critical  success  factors  were  used 
to  set  the  context  for  process  modeling.  The  modeling  effort  reports  to  a  high-level  steering 
committee;  this  committee  checks  the  process  modeling  reports  for  consistency  with  filter- 
up  information. 

In  the  modeling  process,  people  from  the  affected  areas  contributed,  including  cus¬ 
tomers  and  suppliers.  The  activity  proceeded  from  identifying  functions  to  subfunctions  to 
processes.  In  manufacturing  504  processes  were  identified.  All  told,  the  effort  identified 
998  processes  in  260  systems.  There  were  356  information  entities,  of  which  218  occurred 
redundantly. 

From  the  process  model  they  applied  affinity  analysis  to  determine  subjects;  each 
subject  had  a  single  source  of  data  in  enterprise  databases.  ESG  is  using  the  Information 
Engineering  Facility  (lEF)  which  captures  third  normal  form  data  and  constraints  as 
“design  objects.”  The  process  enables  ESG  to  model  data  components.  Constraints  add 
behavior.  A  process  may  have  to  launch  another  process. 
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The  Westinghousc  Integrated  Systems  Environment  (WISE)  manages  the  life  cycle 
for  Parts.  The  electronic  vault  satisfies  CALS  (Computer-Aided  Acquisition  and  Logistics 
Support).  During  design,  the  responsible  designer  controls  the  design  data;  upon  release, 
the  vault  controls  the  data.  WISE  provides  recognition  of  the  source  of  documents  and  con¬ 
trol  of  documents,  including  paper. 

The  Electronic  Assembly  Plant  in  College  Station,  Texas,  has  been  in  operation 
since  1983.  The  CIM  (computer-integrated  manufacturing)  system  acquires  design  data 
and  transforms  it  into  machine  control  data.  A  Standard  Electronic  Assembly  System 
(SEAS)  controls  a  workcell  consisting  of  an  component  insertion  robot,  an  inspection  sta¬ 
tion,  and  a  computer-aided  miscellaneous  operations  station  (where  SEAS  directs  operator 
assembly  of  components  not  suited  for  automated  assembly). 

Integration  Strategies: 

ESG  began  an  enterprise  integration  project  in  1986.  llie  major  steps  are  to  develop 
the  “as  is”  process  model,  to  combine  the  process  model  with  business  directions  and  devel¬ 
op  a  future  enterprise  process  model,  and  then  define  the  implementation  roadmap  to 
achieve  this  target.  In  this  process  ESG  will  develop  an  Enterprise  Business  Model,  an 
Enterprise  Information  Model,  and  an  Operations  System  Blueprint. 

Drivers  for  enterprise  integration  include  competition,  regulations,  and  ii,.aatives. 
Competitive  factors  include  time-to-market.  Initiatives  include  concurrent  engineering, 
CALS  and  ESG’s  Total  Quality  Strategy.  ESG  is  trying  to  tie  concurrent  engineering  and 
CALS  together  in  a  way  that  makes  sense. 

ESG  is  flattening  the  management  tree.  Top  management  is  working  more  closely 
together.  Interdependencies  are  stronger  than  had  been  with  historical  matrix  management. 
A  manager’s  span  of  control  is  increasing. 

ESG’s  Total  Quality  Strategy  addresses  yield  improvement,  consolidation  and  stan¬ 
dardization,  coupling  engineering  and  manufacturing,  and  strategic  sourcing 

Currently,  about  1,000  companies  contribute  to  an  ESG  product,  but  ESG  is  trying 
to  reduce  the  number  of  suppliers.  For  example,  formerly  400  machined  parts  suppliers 
have  been  reduced  to  40.  Consider  both  production  and  logistics  (P&L)  and  investment 
strategies  in  out-sourcing  decisions.  Intepxtte  at  any  site. 

Enterprise  integration  will  enable  information  to  flow  faster  to  places  that  can  uti¬ 
lize  it  Enterprise  integration  facilitates  individuals  working  together,  fostering  communi- 
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cation  over  space  and  time.  The  implementation  strategy  includes  a  Unix  client-server 
network  connecting  multiple  computer  platforms  and  an  integrated  CASE  (computer-aided 
software  engineering)  development  environment. 

WISE  provides  the  infrastructure  for  integration.  In  WISE  there  is  no  charge  for 
Vault  space.  If  there  was,  individual  program  offices  might  reject  using  the  Vault  because 
of  cost. 

The  Advanced  Quality  Engineering  System  (AQES)  is  being  developed  to  apply 
rule-based  expert  systems,  process  capability  databases,  voice  data  entry,  computer  vision- 
based  solder  joint  inspection,  and  other  technologies  in  an  integrated  strategy  to  improve 
non-manufacturing  and  manufacturing  activities  in  the  circuit  card  product  life  cycle. 

Information  Infrastructure: 

In  machining  suppliers,  ESC  has  set  up  equipment  for  digital  data  transfer  (using 
electronic  data  interchange  (EDI))  and  has  trained  the  vendors.  These  are  vendors  for 
whom  ESG  is  the  sole  major  customer,  so  they  would  accept  ESG’s  operating  procedures. 

The  Common  Business  Systems  Library  is  a  DB2  database  and  it  will  migrate  to  the 
lEF  database  over  time.  This  will  imply  a  transition  from  database  design  to  object  design. 
The  lEF  system  generates  code,  leading  to  reduced  maintenance. 

WISE  involves  a  distributed  network,  relational  database,  electronic  vault,  and 
imaging  for  advance  documentation  management.  Cost  data  is  presented  as  approximate 
costs  based  on  a  rolling  average  of  actual  costs. 

There  are  five  kinds  of  networks:  (1)  Apollo  (TCP/IP,  Transmission  Control  Proto- 
colAntemet  Protocol)),  (2)  Sun  (TCP/IP),  (3)  NetBios,  (4)  SNA  (Systems  Network  Archi¬ 
tecture)  and  (5)  DECNet. 

The  standard  parts  database  is  used  in  the  parts  selection  process.  The  data  on  pre¬ 
ferred  parts  include  simulation  models,  cost  to  use,  etc.  There  are  over  10,000  standard 
parts,  plus  “per  contract  parts.”  No  product  can  be  released  until  non-approved  parts  are 
approved. 

The  Vault  enforces  policies  at  events:  (1)  some  rules  are  in  the  database  systems 
with  triggers,  and  (2)  some  rules  are  implemented  in  code.  The  states  are  preliminary, 
released,  and  under  revision.  Everything  in  the  Vault  is  “formatted”  (i.e.,  data  typed), 
including  software  used  to  generate  digital  data. 
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The  controlling  formats  are  “source”  and  translation  (e.g.,  IGES,  the  Initial  Graph¬ 
ics  Exchange  Specification).  IGES  translations  are  not  good  enough,  nowhere  near  100% 
of  the  data  can  be  translated  via  IGES. 

Advanced  documentation  handles  engineering  images. 

AQES  uses  planning  and  rules  in  an  expert  system  for  manufacturing.  It  also  saves 
feedback  information  on  standard  parts,  such  as  fragility  information  or  data  about  the 
effect  of  placement,  and  control  and  manufacturing  data  used  to  define  interfaces  needed  to 
drive  cell  controller  in  its  process  capability  databases. 

Lesson  Learned: 

In  target  modeling  sessions,  stay  away  from  the  organization  structure,  and  elimi¬ 
nate  organization  names  so  turf  issues  are  minimized.  In  modeling  meetings,  stay  awa'' 
from  technology  and  focus  on  business. 

The  justification  for  using  the  Vault  is  by  the  benefits  it  provides  to  programs  that 
use  it  Adoption  is  voluntary  and  is  a  little  less  than  anticipated,  although  there  are  some 
individuals  that  use  it  beyond  the  release  process.  Most  adoptions  are  by  new  programs  at 
start-up  time  (rather  than  converting  a  program  that  is  in  progress).  When  WISE  was  start¬ 
ed,  Westinghouse  was  less  sensitive  to  standards  than  today,  so  it  just  set  Westinghouse 
standards.  Critical  and  needed  standards  are  parts  characterization  and  flexible  data 
exchange. 

Westinghouse ’s  experience  with  the  Electronic  Assembly  Plant  has  been  very  pos¬ 
itive,  as  shown  in  the  following  table  (Table  E-1): 

Table  E-1.  Westinghouse  Electronic  Assembly  Plant  Results 


1981 

1983 

1985 

1987 

1989 

Yields  (first  time  through) 

33 

45 

65 

85 

90 

Cycle  Time  (weeks) 

12 

8 

5 

3 

2 

Relative  Cost 

100% 

92% 

56% 

45% 

33% 
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Industry  2001: 

^  Issues  and  Barriers: 

There  is  an  issue  of  urgency  with  respect  to  standards,  so  Westinghouse  is  not  wait¬ 
ing  for  PDES  (Product  Data  Exchange  Specification),  but  is  using  whatever  is  needed  now. 
This  may  create  a  legacy  issue. 

I  A  big  investment  will  be  required  for  the  cost  of  moving  legacy  systems.  Standard 

names  for  a  PDES  data  dictionary  and  for  EDI  would  help. 
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E.14  ALLISON  GAS  TURBINE,  DIVISION  OF  GENERAL  MOTORS  (GM) 
Description  of  the  Business: 

Develops  and  produces  gas  turbine  engines  for  commercial  and  military  aircraft  and 
power  generation  for  co-generation  and  gas  compression  applications. 

Industry  1993: 

Business  Strategy: 

Allison’s  sales  have  been  about  equally  generated  between  military  and  commercial 
applications.  These  percentages  are  drastically  changing  as  a  result  of  the  significant  reduc¬ 
tions  in  world-wide  military  expenditures.  Consequently,  Allison  has  been  re-engineering 
its  business  structure  to  pursue  and  exploit  new  commercial  market  opportunities  and  to 
respond  to  the  lower  military  volumes  and  programs.  This  new  strategy  requires  a  signifi¬ 
cantly  different  cost  structure  than  has  been  in  place  over  the  past  years  of  government- 
funded  efforts.  To  successfully  compete  in  the  1990s,  considerable  change  is  required. 

Fundamentally,  Allison  is  demassifying  its  business  into  smaller  product-focused 
business  units  focusing  on  product  lines.  This  new  structure  is  essentially  a  “federation  of 
business  units,”  with  each  business  motivated  to  become  a  word  class  competitor  within  its 
market  sector.  This  new  business  architecture  is  key  in  meeting  the  degrees  of  scalability 
and  flexibility  that  ensuing  business  requirements  will  require. 

State  of  Integration: 

The  information  technology  support  at  Allison  must  also  change  to  support  this  new 
business  form.  The  centralized  data  center/common  systems  approach  is  no  longer  capable 
of  reacting  to  the  dynamics  of  a  collection  of  collaborating  business  units.  A  new  approach 
is  also  required  in  delivering  information-related  services.  The  new  approach  treats  the 
delivery  mechanism  as  an  “information  utility”  through  which  services  are  delivered  in  a 
common  manner  to  each  of  the  separate  business  units.  With  these  services,  each  business 
unit  can  create  its  own  “workflow”  or  business  processes  that  best  meet  its  competitive 
requirements.  This  utility  concept  is  currently  being  implemented  at  Allison. 

Information  Infrastructure: 

Allison  is  preparing  to  engage  in  “electronic  commerce”  with  its  trading  partners 
throughout  the  world.  To  successfully  participate  in  the  aerospace  business  today,  extensive 
and  capable  use  of  information  technology  is  imperative.  Current  and  future  business  will 
be  performed  as  collaborative  efforts  called  “virtual  enteiprises.”  These  new  business 
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forms  exist  for  the  duration  of  the  particular  product  that  is  being  jointly  developed  and  pro¬ 
duced  by  the  coalition.  They  are  bounded  together,  through  value-added  communications 
networks,  into  a  single  cohesive  enterprise.  Cooperative  product  design,  development,  and 
production  among  multiple  enterprises  will  be  the  normal  means  for  producing  aerospace 
products  into  the  21st  century. 

A  departure  from  the  hierarchically  organized  infrastructure  is  required  to  achieve 
the  flexibility  and  scalability  to  meet  the  new  architectural  requirements.  Mainframe-based 
data  centers  are  being  replaced  with  client-server  architectures.  Highly  capable  worksta¬ 
tions  connected  to  high  capacity  networks  are  replacing  centralized  applications.  Allison  is 
installing  this  environment  as  part  of  its  re-engineering  effort.  Servers  designed  to  provide 
specific  data,  communications,  and  application  services  are  integrated  into  the  network, 
replacing  general  purpose  computers  that  have  historically  been  used.  Allison’s  philosophy 
emphasizes  that  services  be  delivered  to  each  business  unit  in  a  manner  conducive  to  devel¬ 
oping  innovative  business  processes  that  lead  to  competitive  advantage. 

Lessons  Learned: 

•  Geative  and  intelligent  use  of  information  technology  is  required  to  achieve 
world  class  levels  of  competitive  electronic  commerce 

•  The  dynamics  of  rapid  change  is  forcing  new  approaches  to  both  the  business 
architecture  and  the  information  technology  architecture  which  supports  the 
business. 

•  Aerospace  business  will  be  conducted  via  electronic  commerce  in  the  1 990s  and 
into  the  next  century. 

•  Collaborative  business  arrangements  called  “virtual  enterprises”  will  be  the 
normal  way  of  designing,  developing,  and  producing  both  conunercial  and  mil¬ 
itary  products  throughout  the  1990s  and  beyond. 

Issues  and  Barriers: 

•  Products  conforming  to  international  interoperability  standards  are  not  avail¬ 
able  to  fully  implement  electronic  commerce. 

•  Redesigning  the  enterprise  from  a  military-oriented  process  to  a  market-driven, 
commercially  oriented  enterprise  is  complex  and  time  consuming.  This  transi¬ 
tion  requires  capital  investment  in  both  plant  and  equipment,  and  also,  more 
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importantly,  into  the  retraining  of  the  human  resources.  Obtaining  the  necessary 
capita]  to  complete  this  migration  in  a  reasonable  time  frame  is  a  problem. 

Recommendations: 

Government 

•  The  government  should  promote  high  technology  demonstration  projects. 

•  There  is  need  for  a  high  speed,  high  capability  industrial  “data  highway”  similar 
in  concept  to  the  interstate  highway  system. 

•  There  is  need  to  emphasize  the  agreement  and  acceptance  for  international 
interoperability  standards  and  the  near-term  delivery  of  products  built  to  these 
standards. 

•  The  Federal  taxation  system  should  provide  incentives  for  aerospace  companies 
to  invest  in  re-engineering  their  enterprises  to  full  participation  in  electronic 
commerce. 


E.15  CDI/MODERN  ENGINEERING 


Description  of  *he  Business: 

The  world’s  largest  independent  supplier  of  engineering  design  services  to  the 
automotive  industry.  Three  types  of  contracted  design  services  are  provided: 

•  Contract  design  engineers  as  part  of  an  OEM  (original  equipment  manufacturer) 
team  at  the  OEM  site. 

•  OEM  Manager  who  is  responsible  for  the  project  using  Modem  Engineering 
engineers  and  facilities. 

•  Modem  Engineering  projects  with  their  manager  and  engineers  being  totally 
responsible  for  the  project.  Modem  Engineering  has  total  engineering  facilities 
for  automotive  design  and  concept  development,  including  clay  modeling  and 
prototype  development 

Industry  1991: 

Business  Strategy: 

Modem  Engineering  is  doing  limited  woiit  for  Ford  because  of  its  limited  number 
of  Prime  work  stations.  It  currently  has  20  Prime  work  stations  out  of  a  total  of  600  work 
stations.  Modem  Engineering  is  currently  working  on  the  Ford  Mustang.  The  dies  for  this 
effort  are  being  made  by  a  Japanese  company.  Ford  dies  for  exterior  panels  are  made  pri¬ 
marily  by  offshore  companies.  Currently  there  are  &ve  companies  that  make  dies  for  Ford, 
four  offshore,  and  one  domestic  who  is  filing  for  bankruptcy.  While  Modem  Engineering 
follows  the  design  process  of  the  specific  project  OEMs  it  supports,  it  is  analyzing  the  fea¬ 
sibility  of  having  its  own  design  process.  However,  it  is  quite  concerned  about  what  system 
it  should  use  when  it  gets  heavily  into  solids  modeling.  Modem  Engineering  feels  it  is  in  a 
difficult  situation  with  its  major  customer,  GM,  who  demands  the  use  of  the  CGS  system 
on  its  projects,  and  EDS  who  controls  the  price  of  using  the  CGS  system. 

State  of  Integration: 

The  state  of  integration  within  Modem  Engineering  is  complicated  by  the  demands 
of  the  OEMs  that  Modem  Engineering  use  the  OEM’s  CAD  (computer-aided  design)  sys¬ 
tem  when  engaging  in  product  design  for  that  OEM.  Modem  Engineering  currently  owns 
and  runs  16  different  design  systems  in  order  to  support  its  automotive  industry  clients. 
This  is  further  compounded  when  it  performs  its  finite  element  model  analyses.  Modem 
Engineering  feels  that  upper  management  in  the  Big  Three  wants  a  higher  level  of  informa- 


tion  integration  but  middle  managers  always  find  a  way  to  block  standardization  efforts  that 
would  lead  to  this.  Suppliers  of  hardware  and  software  also  show  no  interest  in  standards. 
Modem  Engineering  estimates  that  this  lack  of  integration  costs  about  20%  in  project  inef¬ 
ficiencies  because  of  designer  training,  re-startup  learning  curves,  and  basic  inefficiencies 
in  the  CAD  systems  whose  use  is  dictated  by  the  Big  Three.  The  European  auto  industry  is 
CATIA  based.  Toyota,  Nissan,  and  Mazda  each  has  its  own  CAD  systems.  Modern  Engi¬ 
neering’s  system  of  choice  is  CATIA.  It  does  as  much  work  as  possible  on  CATIA  and  then 
translates  between  CATIA  and  the  other  OEM  systems,  where  possible,  using  IGES  (Initial 
Graphics  Exchange  Specification). 

Lessons  Learned: 

•  Suppliers  to  the  U.S.  OEMs  find  it  impossible  to  truly  integrate  their  internal 
design  operations  because  of  the  systems  use  demands  made  by  the  OEMs.  It  is 
estimated  that  the  resulting  design  staff  inefficiency  adds  20%  to  the  cost  of 
design  programs. 

•  Suppliers  normally  supply  60  to  70%  of  the  value  to  a  U.S.  vehicle  program. 

•  Suppliers  are  not  big  enough  or  are  unwilling  to  form  a  power  base  to  push  stan¬ 
dards. 

•  Auto  supplier  industry  is  too  fragmented  to  tell  a  large  automotive  company 
what  to  do. 

•  Detroit’s  Big  Three  are  increasing  their  use  of  concurrent  engineering  contracts. 
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E.16  THE  CROSS  COMPANY 
Description  of  the  Business: 

Cross  is  a  medium-size  manufacturer  of  special  high-sp)eed  production  equipment 
(high-speed  transfer  machines).  It  has  operations  in  the  United  States,  Canada,  Europe  and 
Japan.  Cross  products  are  constructed  from  one-third  standard  (off-the-shelf)  components, 
one-third  semi-standard  components  (components  tailored  to  Cross  specifications  by  other 
manufacturers),  and  one-third  clean  sheet  design. 

Industry  1991: 

Business  Strategy: 

Cross  has  cost  justified  an  integrated  set  of  business  and  engineering  systems  by 
comparing  new  systems  against  existing  legacies.  The  Vice  President  of  Business  Opera¬ 
tions  had  to  obtain  approval  of  the  Cross  and  Trecker  Board  to  go  ahead  with  a  new  system 
design  for  enterprise  integration.  The  issues  of  integration  were  determined  to  be  over  50% 
organizational,  cultural,  and  procedural.  Significant  levels  of  training  were  conducted  for 
all  affected  personnel.  EDS  functioned  as  the  systems  integrator.  Ooss  not  only  supplies 
machinery  to  the  Big  Three  automotive  companies  and  it  major  suppliers,  but  also  to  Euro¬ 
pean  automotive  manufacturers  as  well  as  cultivating  business  among  the  Japanese-U.S. 
transplants.  Cross  was  in  the  process  of  building  two  piston-turning  transfer  machines  for 
Muskovich  (a  then-Soviet  engine  manufacturer). 

State  of  Int^ration: 

Cross  has  just  installed  a  highly  integrated  set  of  business  systems  and  procedures 
across  all  domestic  plants.  Most  legacy  systems  were  discarded  during  this  process.  (Dross 
is  currently  running  a  single  computer-aided  design  (CAD)  system.  Because  it  is  a  job  shop 
operation,  the  center  of  its  business  systems  is  a  commercial  MRP-11  system  (manufactur¬ 
ing  resources  planning).  The  design,  evaluation,  training,  and  implementation  of  these  sys¬ 
tems  was  accomplished  during  a  three-year  period.  Training  of  all  personnel,  including  top 
management,  was  considered  to  be  crucial  to  the  success  of  this  implementation.  Cross  is 
on-line  with  the  major  automotive  manufacturers  to  whom  it  supplies  production  machin¬ 
ery.  More  and  more  of  this  machinery  is  being  designed  under  concurrent  engineering  con¬ 
tracts  (Cross  is  part  of  the  product  design  team  which  permits  them  to  optimize  their 
machinery  design). 
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Lessons  Learned: 

The  cost  analysis  developed  by  Cross  to  justify  a  complete  new  system  design  for 
enterprise  integration,  including  scraping  its  legacy  systems,  showed  that  the  existing  (leg¬ 
acy)  system  could  be  economically  replaced  within  a  reasonable  time,  and  would  generate 
an  internal  rate  of  return  of  30%. 

Issues  and  Barriers: 

Barriers  were  primarily  considered  to  be  nontechnical. 

Internal  standards  were  developed  with  the  help  of  EDS,  the  system  integrator. 

Recommendations: 

Industry: 

Cross  felt  that  the  best  chance  for  workable  standards  would  be  to  get  the  major 
companies  behind  the  efforts  of  organizations  like  the  Automotive  Industry  Action  Group 
(AlAG).  However,  at  the  rate  that  companies  are  integrating,  there  will  probably  be  a  set  of 
de  facto  standards. 

Government: 

When  asked  about  the  role  that  the  govoiunent  should  play,  the  comment  was  that 
there  are  sufficient  systems  available  for  industry  to  choose  from  to  accomplish  enterprise 
integration.  It  would  probably  be  best  if  the  government  just  stepped  back  and  let  industry 
do  what  it  has  to  do.  The  government  should  not  try  to  impose  de  facto  standards  of  its  own. 
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E.17  FORD  MOTOR  COMPANY  OF  NORTH  AMERICA 

Description  of  the  Business: 

Major  world  automotive  manufacturer. 

Industry  1991: 

Business  Strategy: 

Ford’s  business  strategy  is  to  maintain  a  competitive  edge  through  the  use  of  its  pro¬ 
prietary  Prime  computer-aided  design  (CAD)  system.  It  considers  Prime  to  be  better  than 
anything  else  and  requires  its  use  by  key  suppliers  if  they  wish  to  sell  to  Ford.  The  CAD 
system  is  bought  by  users  from  Prime.  Ford  has  about  100  engineers  maintaining  their  CAD 
system  at  a  cost  of  over  $10  million  per  year.  However,  it  feels  that  this  is  necessary  to 
maintain  a  competitive  advantage.  Ford  did  admit  that  it  ran  the  risk  of  not  maintaining  a 
competitive  lead,  especially  if  there  was  a  lot  of  software  support  for  systems  other  than 
Prime.  This  is  one  of  the  reasons  for  the  need  to  incur  the  system  maintenance  cost  cited 
above. 

Ford’s  corporate  vision  for  improvement  is  based  on  achieving  quality,  time-to- 
market,  and  cost  improvements.  Ford  monitors  outside  technology  developments  for  those 
it  thinks  will  be  winners,  implementing  them  as  soon  as  possible.  This  creates  a  problem  in 
the  use  of  standards.  It  claims  that  most  good  standards  take  four  to  five  years  to  develop. 
Because  it  feels  its  current  system  gives  it  a  competitive  edge,  Ford  does  not  see  the  need 
to  take  a  leadership  role  in  the  development  of  standards.  However,  it  is  monitoring  the 
progress  being  made  on  standards  and  if  something  comes  of  the  effort,  it  wiil  use  them.  As 
for  now.  Ford  feels  it  is  big  enough  to  require  its  vendors  to  use  the  technology  and  stan¬ 
dards  Ford  needs.  It  is  trying  to  reduce  the  number  of  physical  models  it  develops  from  20 
to  2.  It  is  also  trying  to  implement  CAD  to  milling  clay,  with  the  master-math  model  staying 
in  the  computer.  It  currently  takes  them  three  years  to  completely  develop  a  new  model. 

State  of  Integration: 

Ford  North  America  has  integrated  its  automotive  design  process:  two  CAD  sys¬ 
tems,  a  single  release  system,  and  common  platforms  and  software  across  functional 
groups.  One  CAD  system  is  for  body  panels  and  structure  while  the  other  is  for  compo¬ 
nents.  All  critical  exterior  panels  are  designed  on  its  Prime  proprietary  CAD  system.  TTiis 
is  true  even  if  the  part  is  designed  for  them  by  General  Motors  (GM).  (Case  in  point;  GM 
does  design  and  manufacture  some  body  parts  for  Ford  North  America,  and  had  to  purchase 
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a  Prime  system  to  do  so.)  There  are  currently  about  1,000  copies  of  Ford’s  Prime  CAD  sys¬ 
tem  running  outside  of  Ford,  primarily  by  suppliers  to  Ford.  Ford  makes  the  distinction  of 
who  must  use  Prime,  based  on  a  parts  classification  process: 

•  Class  1 :  Very  critical  and  must  be  designed  on  Prime. 

•  Class  2:  Moderately  critical.  The  Initial  Graphics  Exchange  Specification 
(IGES)  can  be  used  for  data  translation  for  different  CAD  systems. 

•  Class  3:  Not  critical  and  anything  goes. 

While  Ford  Europe  uses  the  same  CAD  (Prime)  and  parts  release  systems  as  Ford 
North  America,  there  is  little  or  no  transatlantic  electronic  transfer  (integration)  of  design 
data. 

There  does  not  appear  to  be  a  common  vision  for  corporate  integration.  The  strategy 
appears  to  be  based  on  the  use  of  common  platforms  and  standards.  Most  standards  fol¬ 
lowed  today  are  Ford  standards,  although  Ford  admitted  to  wanting  international  standards 
so  that  Ford  North  America  and  Europe  could  be  integrated.  Ford  is  now  working  on  estab¬ 
lishing  (defining)  common  data  elements  and  common  business  practices.  It  is  also  inter¬ 
ested  in  re-engineering  this  business  procedures  with  an  eye  towards  corporate  integration. 
Ford  spent  one  year  analyzing  its  clay  to  sheet  metal  process  and  reduced  the  time  by  15%, 
cost  by  10  to  15%,  and  improved  quality. 

Ford  said  that  the  links  between  its  product  design  data,  CAD,  and  computer-aided 
engineering  (CAE)  tools  were  not  as  good  as  it  would  like  to  see.  One  reason  for  improving 
this  linkage  is  to  do  a  better  job,  electronically,  of  crash  analysis.  The  alternative  is  model 
crash  testing  to  satisfy  federal  requirements. 

Information  Infrastructure: 

Two  CAD  systems: 

•  A  single  release  systems 

•  IBM,  DEC,  Apollo  and  Sun  engineering  work  stations 

•  A  Texas  Instruments  dealer  system  which  is  going  toward  Unix 

•  Component  plants  run  HP  floor  systems 

•  Powertrain  plants  run  DEC 
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Lessons  Learned: 

•  If  PDES  (Product  Data  Exchange  Specification)  was  available.  Ford  might  use 
it. 

•  Product  data  should  be  separate  from  infrastructure. 

•  They  cannot  easily  tie  alphanumeric  information  to  CAD  surfaces. 

•  There  was  a  major  study  four  years  ago.  A  team  of  10  to  1 5  people  spent  a  year 
benchmarking  the  process  of  going  from  clay  to  tools. 

•  Ford  is  reluctant  to  make  major  changes  to  current  system. 

•  Supplier  of  Ford  surfaces  must  use  its  Prime  CAD  system. 

•  Supplier  integration  is  fairly  good. 

•  Ford  is  following  PDES  efforts  and  could  be  very  active  if  necessary,  but  there 
is  no  current  interest  in  helping  to  define  standards. 

•  Ford  has  been  using  stick  figures  in  design  for  15  years. 

•  It  has  a  proprietary  computerized  crash  system. 

•  It  is  now  developing  a  solid  modelling  package. 

•  Open  systems  are  gaining  in  Ford,  e.g.,  its  Dealer  system  was  a  Texas  Instru¬ 
ments  system  but  is  now  becoming  more  open  (i.e.,  Unix  based). 

•  It  is  moving  to  one  system  for  office  automation. 

•  Ford  Europe  is  moving  to  OSI  (Open  System  Intercoimection). 

•  AIAG  (Automotive  Industry  Action  Group)  is  looking  for  standard  commonal¬ 
ity  but  not  moving  fast  enough. 

•  Systems  should  assist  globalization. 

•  Government  pushes  technology. 

•  The  Computer-Aided  Acquisition  and  Logistics  System  (CALS)  seems  to  be 
using  the  technique  of  implementation  through  military  specifications. 

•  The  National  Institute  of  Standards  and  Technologies  (NIST)  needs  help  from 
international  companies  to  establish  standards. 
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Recommendations: 


Industry: 

AIAG  should  move  faster  towards  standards  in  CAD  and  electronic  data  inter¬ 
change  (EDI). 

Government 

The  government  should  get  involved  in  standards  setting,  but  it  is  questionable  how 
far  it  should  go. 
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E.18  GENERAL  MOTORS  /  CHIEF  INFORMATION  OFFICER 
Description  of  the  Business: 

World-wide  manufacturer  of  transportation  vehicles  and  systems. 

Industry  1991: 

Business  Strategy: 

For  enterprise  integration  to  be  successful,  all  stakeholders  and  their  needs  must  be 
identified  and  balanced.  The  following  model  was  suggested: 

Stakehoiders/Needs 

•  Customers  (quality,  price,  availability,  lead  time) 

•  Employees  (pleasant  work  environment,  informed,  creative  tasks) 

•  Suppliers  (stability  in  demand,  easy  information  exchange) 

•  Stockholders  (return  on  investment) 

•  Managers  (easily  digested  current  information) 

Information  plays  a  key  role  in  satisfying  each  stakeholder  and  there  should  be  a 
strategy  to  satisfy  each  one.  Management’s  role  is  to  determine  these  strategies  and  satisfy 
(balance)  the  stakeholders.  Interconnectivity  and  interoperability  in  and  across  corporate 
boundaries  are  critical.  If  standards  do  not  exist,  complexity  and  duplication  results.  When 
companies  come  to  apply  information  technology  they  find  a  myriad  of  solutions  to  satisfy 
basic  functions.  The  more  solutions  in  use  by  a  company,  the  more  people  and  training  is 
required.  Enterprise  integration  needs  standards.  No  company  alone  can  influence  enough 
of  the  outside  world  to  standardize  the  systems  offerings.  Standards  that  are  currently  in 
place  are  mostly  industrially  based.  Within  the  automotive  enterprise  AIAG  (Automotive 
Industry  Action  Group)  is  attempting  to  set  integration  standards  in  several  areas  but  it  is 
moving  too  slowly. 

State  of  Integration: 

Because  of  the  history  of  General  Motors  (GM),  independently  information  sys¬ 
tems  were  developed  and  operated  within  its  many  operating  divisions.  This  resulted  in  GM 
running  as  many  as  10  different  CAD  systems  and  many  sets  of  business  systems.  It  now 
has  a  single  corporate  vision  for  corporate  integration  and  all  divisions  will  work  toward 
the  implementation  of  this  vision.  According  to  an  AIAG  report,  the  GM  C-4  program^  for 
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product  engineering  will  reduce  the  number  of  CAD  systems  to  four,  including  the  Corpo¬ 
rate  Graphics  System  (CGS),  CADAM  and  Unigraphics. 

Information  Infrastructure: 

Information  infrastructure  comprises  hardware,  operating  systems,  programming 
languages,  and  communications,  but  not  applications.  The  government  has  a  role  in  estab¬ 
lishing  infrastructure  standards  that  would  aid  interoperability  and  connectivity.  It  has  a 
lesser  role  in  application  standards. 

Issues  and  Barriers: 

GM  is  very  active  in  activities  such  as  CALS  (Computer-Aided  Acquisition  and 
Logistics  Support).  It  is  also  very  active  in  industrial  cooperative  effons  such  as  ALAG,  the 
National  Center  for  Manufacturing  Sciences  (NCMS),  the  Microelectronics  and  Computer 
Technologies  Corporation  (MCC),  the  Corporation  of  Open  Systems  (COS)  and  SOS. 

Recommendations: 

The  government  has  a  role  in  pushing  standards  for  integration  infrastructures  but 
not  applications.  Most  companies  would  also  welcome  government  intervention  in  setting 
standards  for  both  Japan  and  Europe. 
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C4  =  Computer-Aided  Design  (CAD),  Computer-Aided  Manufacturing  (CAM).  Computer-Aided  Engi¬ 
neering  (CAE),  Computer-Integrated  Manufacturing  (CIM). 


E.19  RYOBI  DIE  CASTING  (USA),  INC. 

Description  of  the  Business: 

Ryobi  Die  Casting  (USA),  Inc.,  is  a  wholly  owned  U.S.  subsidiary  of  a  Japanese 
firm  (Ryobi,  Ltd.)  that  has  grown,  world-wide,  by  selectively  procuring  companies  that 
could  be  vertically  integrated  into  its  primary  line  of  business,  i.e.,  producers  of  die  cast 
components.  Ryobi  Die  Cast  produces  precision  die  cast  parts  for  the  automotive  industry, 
both  commercial  and  farm  vehicles.  Its  biggest  customer  is  Ford. 

Industry  1991: 

Business  Strat^: 

Ryobi  is  trying  to  reduce  dependency  on  automotive  business.  It  feels  that  pressure 
from  the  automotive  industry  to  reduce  cost  is  putting  unreasonable  burden  on  the  supplier 
community.  Ford  is  currently  asking  it  for  a  4%  reduction  each  year  with  little  relief  in 
design  specifications.  The  result  is  that  there  is  insufficient  profit  remaining  for  productivity 
investment  Ryobi  is  also  operating  a  small  transfer  line  operation  for  Ford.  The  equipment 
and  the  processing  belong  to  Ford  but  the  people  and  the  daily  operation  are  managed  by 
Ryobi.  Die  and  advanced  processing  development  for  the  Ryobi  plant  is  currently  being 
done  in  Japan  at  its  corporate  tech  center.  Part  data  is  sent  to  Japan  via  tape.  Ryobi  USA 
does  intend  to  be  on-line  with  Ryobi  Japan  for  business  reporting. 

Working  with  General  Motors  (GM)  on  computer-aided  design/computer-aided 
manufacturing  (CAD/CAM)  projects  is  expensive  because  GM’s  CGS  (Corporate  Graph¬ 
ics  System)  is  not  as  efficient  as  other  CAD  systems.  (Comments  offered  by  Mr.  Fant  based 
on  his  experience  while  working  at  Modem.) 

Ryobi  has  had  some  problems  with  integration  because  of  its  customers  having  dif¬ 
ferent  standards  and  different  CAD  systems.  However,  CATIA  is  becoming  the  prevalent 
CAD  system  across  its  customer  base.  It  feels  there  is  a  need  for  enterprise  integration  stan¬ 
dards  in  the  automotive  enterprise,  but  the  Big  Three  are  not  dedicated  to  having  a  single 
oversee  system  for  integration  with  their  suppliers.  The  Automotive  Industry  Action  Group 
(AIAG)  is  a  good  organization  working  towards  standards  for  integration  but  it  is  not  get¬ 
ting  the  top  management  support  it  needs. 
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State  of  Integration: 

Ryobi  is  experiencing  more  use  of  concurrent  engineering  contracts,  and  as  a  result, 

is  installing  workstations  to  be  able  to  communicate  on-line  with  Ford  and  probably  GM. 

They  plan  to  use  IGES  (the  Initial  Graphics  Exchange  Specification)  as  a  translator. 

Lessons  Learned: 

•  Automotive  suppliers  are  actively  looking  for  other  industries  to  supply  outside 
of  the  automotive  industry.  Ryobi ’s  management  was  under  the  impression  that 
this  was  a  general  trend  within  the  automotive  supplier  base. 

•  U.S.  subsidiaries  of  Japanese  firms  are  still  doing  most  of  their  product  engi¬ 
neering  and  process  development  in  Japan  for  their  U.S.  operations.  There  does 
not  appear  to  be  an  overwhelming  rush  to  change  this. 

Recommendatitms: 

Government: 

The  government  should  ease  some  trade  regulations. 
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E.20  SATURN 


Description  of  the  Business: 

SATURN  is  a  new  division  of  General  Motors  (GM)  which  was  established  to  com¬ 
pete  with  the  Japanese  in  the  manufacture  and  sales  of  small  cars.  SATURN ’s  advanced 
engineering  and  business  functions  are  located  in  Troy,  Michigan.  Its  manufacturing  facil¬ 
ities  are  located  in  Spring  Hill.  Tennessee. 

Industry  1991: 

Business  Strategy: 

The  mission  statement  includes  the  integration  of  people,  technology,  and  business 
systems.  Business  partners  were  selected  on  their  ability  and  willingness  to  become  part  of 
the  enterprise.  This  includes  both  engineering  services  as  well  as  parts  suppliers.  Partner¬ 
ship  includes  sharing  of  both  risk  and  reward.  SATURN  is  a  partnership  with  the  UAW 
(United  Auto  Workers),  and,  as  such,  all  manufacturing  people  and  cultural  issues  associ¬ 
ated  with  integration  were  jointly  addressed  and  resolved  before  the  plant  and  system 
design  was  initiated. 

State  of  Integration: 

SATURN  has  achieved  broad  internal  integration  across  all  information  functions 
of  the  company:  business,  engineering,  and  manufacturing.  This  is  clearly  indicated  by  part 
of  the  mission  statement:  “The  integration  of  people,  technology,  and  business  systems.” 
Very  few  legacy  systems  were  brought  in  from  GM.  The  design  of  the  new  system  was 
based  on  the  following: 

Single  computer-aided  design  (CAD)  system 

Single  logical  data  base 

Standard  communication  protocols 

Reusable  software  applications  across  business  functions 

Common  hardware  platforms 

Distributed  architecture 

SATURN  business  partners  have  access  to  all  information  and  people  needed  to 
integrate  their  products  and  process  into  the  SATURN  business.  The  physical  manufactur¬ 
ing  complex  has  integrated  all  major  components  made  in  Spring  Hill  as  well  as  off-site 
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parts  shipped  in  just-in-time  (JIT).  The  complex  was  designed  to  facilitate  a  JIT  inventory 
control.  Extremely  low  levels  of  inventory  are  maintained  in  the  plant  (e.g.,  30  minutes  for 
built-up  engine  blocks). 

Information  Infrastructure: 

SATURN  selected  CATTA  as  its  single  CAD  system.  Because  of  the  timing  of  the 
product  design,  GM’s  CGS  (Corporate  Graphics  System),  CAD  AM,  and  CATIA  were  ini¬ 
tially  used.  After  the  selection  of  CATIA,  all  new  designs  have  migrated  to  CATIA.  SAT¬ 
URN  feels  that  a  single  CAD  system  for  all  design  gives  it  a  strategic  advantage.  It  appears 
to  be  very  close  to  a  single  logical  data  base.  Data  elements  which  are  used  by  multiple 
business  functions  are  in  one  data  base,  with  elements  specific  to  one  business  function 
being  in  individual  functional  data  bases.  All  plant  systems  are  run  on  DEC  ph  f  jrms  with 
conunon  applications  running  in  all  manufacturing  operations.  Their  common  applications 
are  based  on  the  GEF  Complicity  software  enablers.  Standards  for  all  plant  floor  systems 
were  given  to  all  equipment  suppliers  before  they  designed  the  software  specific  to  their 
equipment  m  coordinated  the  design  and  necessary  education  for  these  standards.  The 
standards  included  the  following: 

•  Communications 

•  Software  enablers 

•  Man-machine  interface 

•  Platforms 

•  Software  design 

•  Architecture 

The  plant  complex  now  runs  four  interconnected  Manufacturing  Autontation  Pro¬ 
tocol  (MAP)  3.0  networks,  with  critical  information  on  inventory,  scheduling,  and  equip¬ 
ment  status  accessible  across  the  total  con^lex. 

Data  models,  information  flow  models,  and  existing  reference  models  were  all  used 
in  the  design  of  the  information  systems.  Other  programs  used  to  improve  product  design, 
quality,  and  time-to-market,  such  as  Total  (^ality  Management  (TQM),  Design  for  Assem¬ 
bly  (DFA),  (Quality  Function  Deployment  (QFD),  Continuous  Improvement  (Cl),  and  con¬ 
current  engineering,  are  in  use  at  SATURN. 
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Lessons  Learned: 


Manufacturing  lessons 

•  Standards  are  essential. 

•  Make  use  of  strategic  partners. 

•  Focus  on  applications  rather  than  developnrent. 

•  A  wide  variety  of  the  business  can  use  common  software. 

•  Linking  between  floor  devices  is  of  primary  importance. 

•  Manufacturing  should  be  responsible  for  plant  systems. 

•  MAP  network  direction  was  correct 

•  Distributed  processing  is  correct  for  manufacturing. 

•  Workers  need  to  be  involved  in  plant  systems. 

•  Existing  plants  can  implement  integrated  systems  in  phases. 

Product  Engineering  Lessons 

•  Data  ownership  becomes  data  administration. 

•  Determining  the  value  of  intelligent  numbers  to  the  organization  is  critical. 

•  Change  management  for  highly  integrated  information  systems  requires  a  high 
degree  of  coordination. 

Powertrain  lessons 

•  DNC  is  not  practical  for  high  volume  production. 

•  Integration  of  manufacturing  has  high  payoff  in  lowering  inventory  and  increas¬ 
ing  equipment  utilization. 

•  People  will  use  real-time  information  if  it  is  provided  to  the  production  floor. 
Issues  and  Barriers: 

Plant  floor  standards  were  developed  by  ITl  for  SATURN,  using  existing  national, 
international,  and  GM  standards. 

Without  the  people  issues  first  being  addressed  at  SATURN,  the  demonstrated  level 
of  integration  would  not  have  been  possible. 
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E.21  UNIVERSITY  OF  MICHIGAN;  DIRECTOR/OFnCE  FOR  THE  STUDY 
OF  AUTOMOTIVE  TRANSPORTATION 

Description  of  the  Business: 

The  University  of  Michigan’s  Office  for  the  Study  of  Automotive  Transportation 
(OSAT)  was  established  to  analyze  the  automotive  industry,  world-wide.  The  following 
report  is  a  summary  of  OSAT’s  conclusions  concerning  the  enterprise  integration  of  the 
industry.  All  of  its  comments  are  documented  under  the  lessons  and  conclusions  section. 

Industry  1991: 

Lessons  Learned: 

Technology  and  systems  are  the  least  important  part  of  the  integration  problem  in 
the  automotive  industry.  People’s  resistance  to  change  and  cultures  is  the  basis  for  most  of 
the  problems.  Most  of  the  current  managers  in  the  automotive  industry  grew  up  under  the 
Taylor  Philosophy  where  team  play  was  not  rewarded.  Automotive  companies  are  using 
short-term  mentalities  when  it  comes  to  measurements  and  rewards.  The  Automotive 
Industry  Action  Group  (AlAG)  is  currently  working  on  computer-aided  design/computer- 
aided  manufacturing  (CAD/CAM)  standards.  This  work  needs  to  be  speeded  up  but  there 
is  a  lack  of  strategic  understanding  of  the  CAD/CAM  technical  and  integration  issues  at  the 
upper  management  level  in  the  original  equipment  manufacturers  (OEMs). 

Strategic  partners  are  treated  very  differently  at  different  companies  and  divisions 
within  companies.  Chrysler  is  treating  its  suppliers  more  like  strategic  partners  than  anyone 
else.  GM’s  3-2-2  cost  reduction  program  is  not  timed  or  coordinated  properly  with  its  man¬ 
ufacturing  and  engineering  activities.  These  activities  are  very  reluctant  to  change  part 
Reifications  or  costly  practices  which  would  help  the  parts  suppliers  reduce  cost  Some 
level  of  integration  is  taking  place  at  the  powertrain,  body  and  assembly,  and  electronics 
systems  level.  The  OEMs  cannot  afford  to  continue  duplication  in  these  systems.  They  are 
undertaking  several  cooperative  research  programs  such  as  electric  batteries  for  their  elec¬ 
tric  car  programs.  The  federal  government  has  been  known  as  a  regulator  and  its  image 
must  change  to  become  an  effective  paitner. 

During  the  last  several  years,  experiments  have  been  taking  place  in  the  automotive 
industry  ffom  which  we  will  now  begin  to  harvest  the  results.  The  1980s  was  the  decade  of 
understanding,  the  1990s  will  be  the  decade  of  execution,  and  the  2000s  will  be  manage¬ 
ment  of  knowledge.  There  will  be  comprehensive  corporate  data  bases  and  their  manage¬ 
ment  will  be  key.  The  three-day  car  will  be  a  reality  but  not  with  custom  skins.  Cars  will  be 
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revitalized  or  updated  at  50,000  mile  intervals  with  new  electronics,  graphics,  and  safety 
features.  Transportation  will  have  to  be  provided  to  the  “have  nots”  of  society  through  revi¬ 
talized  vehicles.  More  flexibility  will  be  needed  in  all  parts  of  the  production  cycle.  The  24- 
hour,  3-crew  plant  will  become  more  common  to  increase  the  utilization  of  our  capital. 
Fewer  strategic  partners  will  be  providing  more  of  the  vehicle  as  total  systems.  More  cars 
produced  with  a  fewer  number  of  parts  will  be  the  norm  in  the  future,  e.g.,  more  common 
parts  will  be  used  across  car  lines.  These  concepts  will  require  a  whole  new  dimension  of 
information  tracking  down  to  the  part  level. 
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E.22  GENERAL  ELECTRIC  AIRCRAFT  ENGINES 


Description  of  Business 

General  Electric  Aircraft  Engines  (GEAE)  is  one  of  two  U.S.  nianufacturers  of  gas 
turbine  engines  for  both  commercial  and  military  use,  and  along  with  Rolls  Royce  and  Pratt 
and  Whitney,  is  one  of  the  three  major  gas  turbine  engine  producers  in  the  world.  GEAE’s 
large  gas  turbine  engines  are  designed  and  manufactured  in  Cincinnati,  Ohio.  Smaller  gas 
turbine  engines  are  produced  by  the  GEAE  division  in  Lynn,  Massachusetts.Our  enterprise 
integration  interviews  were  with  the  large  engine  division  in  Cincinnati. 

GEAE  has  been  a  leader  in  developing,  producing,  and  supplying  gas  turbine 
engines  to  the  worldwide  airline  market  since  the  advent  of  commercial  jet  aircraft.  The 
commercial  product  line  was  an  outgrowth  of  its  military  engine  line,  GEAE  being  the  first 
U.S.  company  to  develop  and  produce  a  turbojet  engine  early  in  the  1940s. 

Industry  1993: 

Business  Strategy: 

GEAE  is  dedicated  to  having  enterprise  integration  in  place  throughout  the  compa¬ 
ny  as  quickly  as  possible.  As  part  of  the  process,  the  company  has  set  a  1995  target  of  hav¬ 
ing  enterprise  integration  fully  deployed  throughout  engineering  and  manufacturing.  The 
justification  for  enterprise  integration  is  the  return  on  investment  benefits.  To  this  end, 
GEAE  has  been  collecting  some  metrics  and  has  stated  its  intent  to  do  so  in  a  more  aggres¬ 
sive  manner  on  the  basis  that  the  need  to  justify  such  investment  is  more  critical  during  the 
recent  downturn  in  overall  aviation  business. 

Enterprise  integration  will  be  deployed  both  externally  as  well  as  internally.  GEAE 
has  started  to  link  itself  with  its  primary  suppliers  and  will  continue  the  process.  The  com¬ 
pany  acknowledges  that  as  they  go  deeper  into  their  supplier  network,  companies  tend  to 
get  smaller  in  size.  Unfortunately,  some  of  the  suppliers  are  not  large  enough  to  justify  or 
see  the  need  to  link  electronically.  The  decision  whether  or  not  to  stay  with  these  small 
companies  has  yet  to  be  made.  Over  the  past  three  years,  GEAE  has  reduced  its  number  of 
suppliers  to  some  extent.  During  the  recent  downturn  in  business,  GEAE  found  that  it  had 
to  hold  the  line  on  prices  in  order  to  retain  market  share.  And,  in  turn,  GEAE  expects  its 
suppliers  also  to  reduce  their  costs  wherever  possible. 
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Status  of  Integration: 

In  the  late  1980s,  GEAE  began  to  focus  around  the  process  of  an  engine  develop¬ 
ment  cycle  from  early  conception  of  concepts  and  technology  through  customer  product 
requirements,  product  design,  manufacture,  delivery,  and  field  support.  Two  parallel  master 
plans  were  defined  (Engineering  and  Manufacturing  Computations  Master  Plans).  These 
plans  focused  on  limiting  the  number  of  hardware  platforrsiS  and  operating  systems  to 
ensure  compatibility  of  engineering  and  manufacturing  applications  to  maximize  process 
efficiency  across  functions  instead  of  previously  suboptimizing  functional  applications 
with  too  little  regard  for  functional  interoperability. 

Both  master  plans  focused  on  a  strategic  selection  of  a  software  vendor  to  provide 
common  product  gecnetric  definition  from  design/analysis  through  drafting,  manufactur¬ 
ing  planning,  and  inspection  automation.  Unigraphics  was  selected  as  that  supplier  in  1990. 
By  1996,  Unigraphics  will  provide  this  basis  for  common  geometric  master  models  across 
turbo-machinery  for  all  product  lines.  Unigraphics  currently  penetrates  about  25%  of  its 
planned  implementation  level;  several  component  design  scenarios  have  adopted  the  con¬ 
current  engineering  process  based  on  the  common  geometry  approach  and  have  demon¬ 
strated  significant  improvements  in  both  speed  and  quality  (design/manufacturing  release 
cycle  reduced  an  average  of  30%  while  improving  quality  by  more  than  doubling  the  ana¬ 
lytical  iterations  and  concurrently  preparing  the  manufacturing  process). 

While  attempting  to  move  to  internal  standards  for  process  efficiency,  GEAE  rec¬ 
ognizes  the  need  to  concurrently  integrate  its  propulsion  system  designs  with  the  customer. 
Since  1987,  GEAE  has  been  working  towards  the  c:q>ability  of  digitally  exchanging  the 
propulsion  system  geometric  representation  in  the  concept-to-design  evolution  with  its  cus¬ 
tomer  (Boeing  on  the  new  777  aircraft).  This  Digital  Pre-Assembly  (DPA)  and  Digital 
Mock  Up  (DMU)  process  is  utilized  to  evolve  the  configuration  design  of  the  externals  of 
the  engine  concurrently  with  the  turbo  machinery  design  instead  of  the  sequential  process 
that  historically  had  been  ^plied. 

A  comparison  of  the  new  GE90  engine  design  process  as  compared  to  the  CF6-80C 
engine  development  about  a  decade  earlier:  The  CF6-80C2  engine,  which  went  to  test  in 
March  of  1984,  had  455  tubes  and  brackets  on  the  first  engine  to  test.  By  the  time  that 
engine  was  delivered  to  test,  1,056  tubes  and  brackets  had  been  designed  and  released. 
Approximately  50%  of  that  excess  was  in  hardware  by  the  time  it  was  found  that  they  had 
interferences  with  other  hardware  or  no  longer  met  the  design  intent  or  customer  compati¬ 
bility. 
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On  the  other  hand,  the  GE90  engine  first  to  test  had  four  niinor  tube  rework  and  first 
time  hardware  assembly  with  no  interferences.  This  process  now  allows  GEAE  to  design 
configurations  of  engines  with  the  customer  while  no  longer  using  physical  mock-ups  for 
design  resolution. 

The  DPA/DMU  process  is  currently  being  applied  to  the  FI 8  E/F  -  F414  engine 
development  program  using  Unigraphics  to  perform  the  customer  design  concurrency  with 
McDonnell  Douglas  and  Northrop. 

GEAE’s  future  DPA/DMU  process  will  be  applied  to  new  development  programs 
on  a  CAD  system  that  was  selected  for  customer  compatibility  until  standards  for  CAD  sys¬ 
tem  exchange  of  geometry  (like  STEP,  the  Standard  for  the  Transfer  and  Exchange  of  Prod¬ 
uct  data)  are  robust  enough  to  accommodate  an  inter-CAD  system  concurrency  of  design. 

More  historically,  GEAE  began  an  initiative  in  1984  to  accommodate  digital  cre¬ 
ation,  modification,  retention,  and  distribution  of  engineering  drawings  regardless  of  the 
drawing  source  (CAD  system,  drafting  board).  ADSRS  (Automated  Drawing  Storage  and 
Retrieval  System)  reached  its  production  critical  mass  in  1 986  and  was  digitally  integrated 
with  a  Raster  CAD  system  for  drawing  revision  and  issuance  in  1988.  There  are  currently 
1.7  million  drawing  images  in  the  system  which  are  digitally  accessible  from  GEAE  sites 
across  the  United  States. 

In  1988,  a  three-month  measured  comparison  of  the  digital  change  incorporation 
process  (using  FORMTEK)  to  the  manual  process  of  drawing  change  incorporation  was 
performed.  The  process  of  incorporating  changes  on  the  drawing  by  the  draftsmen  averaged 
eight  man-hours  per  change  on  the  board;  the  digital  change  incorporation  on  a  Raster 
drawing  averaged  four  hours.  (This  does  not  include  the  efficiency  of  avoiding  plotting, 
manual  handling  of  the  tracing,  and  manual  transfer  of  documents.)  These  savings  map  into 
about  80,000  man-hours  a  year  (averaging  20,(X)0  drawing  changes  each  year). 

'fhis  digital  drawing  system  has  been  directly  interfaced  with  the  Air  Force 
EDGARS  system;  the  first  digital  data  buy  out  was  delivered  to  EDGARS  in  1991.  This 
reduced  the  cycle  for  complete  technical  data  delivery  on  the  FI  10-100  engine  from  previ¬ 
ous  cycles  of  over  1  year  to  about  10  weeks.  The  current  10- week  cycle  could  be  further 
reduced  pending  input  capacity  of  EDGARS. 

On  the  GF680GX  wide  chord  fan  blade  engine,  GEAE  was  able  to  reduce  the  cycle 
time  from  design  start  to  manufacturing  design  release  by  40%  over  the  previous  engine 
design  program,  with  time  to  do  three  complete  design  iterations. 
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GEAE  has  completed  the  process  of  identifying  its  core  business  and  is  now  iden¬ 
tifying  the  data  required  to  support  its  core  business.  After  standardizing  at  this  level,  the 
data  system  that  finally  emerges  will  work  outward  from  the  core  business. 

As  part  of  the  enterprise  integration  deployment  process,  GEAE  documented  its 
business  processes,  along  with  the  data  requirements  for  each  business  process.  GEAE  has 
now  undertaken  a  program  to  re-engineer  its  business  process  under  a  program  that  calls 
for  continual  business  process  improvement 

From  a  data  management  program  point  of  view,  GEAE  is  placing  its  enterprise 
integration  efforts  on  Integrated  Management  System  90  (IMS  90).  There  are  four  levels  of 
data  control. 


Table  E-2.  Levels  of  Data  Control 


Level  4: 

Corporate  Host 

Finance,  Administration,  Purchasing,  Master 
Schedule,  etc. 

Level  3: 

Plant  Host 

Production  Schedule,  Maintenance  Inventory 
Control 

Level  2; 

Workstation  Control¬ 
ler 

QA  (Quality  Assurance)  Management,  Cell  Coor¬ 
dination 

Level  1: 

Direct  Control 

C!NC  (Computer  Numeric  Control),  CMM  Coor¬ 
dinate  Measuring  Machine),  Robotics 

After  reviewing  the  problem  internally,  GEAE  found  that  software  and  data  are 
always  being  recreated  within  the  Company.  By  integrating  the  data  management  system, 
this  represents  an  opportunity  for  big  savings.  GEAE  is  picking  IRDS  (Information 
Resource  Dictionary  System)  as  the  data  modeling  standard  (because  it  exists).  Knowl- 
edgeware  is  being  used  to  model  the  data  and  processes  within  GEAE. 

Barriers: 

The  greatest  barrier  to  enterprise  integration  is  lack  of  standards.  Mthout  them, 
geometry  is  not  sharable.  STEP,  in  part,  addresses  configuration  management  across  the 
design  process,  whereas  other  standards  do  not.  The  need  for  standards  is  very  apparent  in 
the  case  of  companies  like  GEAE  whose  interfacing  requirements  outside  of  the  company 
are  international  in  scope.  GEAE’s  CAD  preference  is  Unigraphics.  On  the  other  hand, 
Boeing  requires  the  use  of  CATIA.  Snecma  and  Airbus  also  require  CATIA  but  they  are 
also  using  STEP.  GEAE  has  found  IGES  (the  Initial  Graphics  Exchange  Specification)  to 


be  no  solution.  As  an  example,  for  one  of  the  engines,  GEAE  designs  the  compressor  fan 
blades.  The  design  is  passed  to  Snecma  for  production.  In  turn,  Snecma  designs  the  com¬ 
pressor  blades,  whose  design  is  passed  to  GEAE  for  production. 

GEAE  firmly  believes  that  in  order  to  incorporate  STEP  in  a  CAD  supplier’s  soft¬ 
ware,  government  funding  will  play  a  key  role  and  should  be  made  available  to  the  industry 
as  soon  as  possible.  This  initiative  will  deliver  immense  benefits  to  both  defense  and  com¬ 
mercial  sectors. 

A  second  barrier  to  be  faced  by  enterprise  integration  is  the  handling  of  proprietary 
information.  In  the  case  of  GEAE,  for  example,  its  programs  bring  it  into  contact  with  pro¬ 
prietary  data  from  Boeing,  Airbus,  Snecma,  McDonnell-Douglas,  Canadair,  Northrop, 
Lockheed,  and  other  airframers.  The  legalities  of  properly  handling  another  company’s  data 
can  approach  those  associated  with  handling  government  classified  data. 

A  third  barrier  is  the  readiness  and/or  willingness  of  outside  companies  (suppliers 
and  customers)  to  be  enterprise  integration  compatible  with  GEAE.  And  it  is  not  only  the 
intent  of  becoming  compatible,  but  also  a  matter  of  timing,  A  small  company  that  GEAE 
is  dependent  upon  but  whose  financials  will  not  permit  it  to  become  enterprise  integration 
compatible  with  GEAE  until  many  years  after  GEAE  is  up  and  running  with  most  of  its  sup¬ 
pliers/customers,  will  force  GEAE  into  operating  a  dual  (old  and  new)  communication  sys¬ 
tem  long  after  GEAE  has  totally  deployed  enterprise  integration  internally. 

When  asked  about  legacy  systems,  GEAE  admitted  that  they  are  a  problem  but  less 
of  a  problem  when  compared  to  the  “soft  issues”  of  culture  and  management  Within  engi¬ 
neering  and  manufacturing,  data  bases  are  being  converted  as  needed.  Where  interfaces 
exist  or  can  be  easily  developed  to  avoid  conversion,  they  are  being  used.  Like  airframe 
manufacturers,  many  data  bases  must  be  saved  in  their  original  format  to  satisfy  legal 
requirements  should  warrantee  or  safety-of-flight  issues  arise  many  years  after  an  engine 
has  been  produced.  To  begin  to  fix  the  problem,  GEAE  has  identified  three  levels  of 
required  systems  and  services:  (1)  Enteiprise  databases  (MVS,  DB2,  IDMS — ^hold  90%  of 
the  data);  (2)  Work  group  data  bases  (VMS/Ingres,  UNIX/Ingres,  Novell  Oracle);  and  (3) 
personal  data  bases.  The  goal  is  to  have  a  standard,  open,  scaleable  system  which  will  be 
accessible  across  the  enterprise.  To  start,  GEAE  picked  the  minimal  interface  protocols 
(Network  File  System  (NFS),  Transmission  Control  Protocol/Intemet  Protocol  (TCPAP)) 
to  accomplish  this. 
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Industry  2001: 

GEAE’s  intent  is  to  be  totally  paperless  where  it  makes  good  business  sense.  Cer¬ 
tainly  within  engineering  and  manufacturing,  there  will  be  a  seamless  operation  that  sup¬ 
ports  a  true  concurrent  engineering  environment.  The  target  of  1995  for  the  fully  integrated 
engineering  and  manufacturing  environment  appears  to  be  a  reality,  given  the  progress 
made  to  date.  The  issue  of  integrated  data  management  remains  to  be  worked  out,  however. 

Steps  are  well  under  way  to  be  electronically  integrated  externally  as  well  as  inter¬ 
nally.  GEAE  is  in  the  position  of  having  pressure  brought  from  both  internal  and  external 
sources  for  enterprise  integration.  Its  military  customer  is  starting  to  demand  electronic 
delivery  of  products  as  a  contractual  requirement.  Many  of  its  civil  aviation  customers  are 
relying  on  electronic  ordering  to  shorten  the  support  pipeline  and  reduce  spare  parts  inven¬ 
tories.  GEAE,  in  re-engineering  its  business  processes,  is  finding  it  more  cost  effective  to 
be  electronically  integrated  with  its  suppliers  and  is  striving  to  accelerate  the  process  of 
total  enterprise  integration. 

The  issue  of  when  and  where  to  make  Ae  enterprise  integration  investment  is  par¬ 
ticularly  cridcal  today.  Since  GEAE  recognizes  Aat  Ae  enterprise  integration  mvestment 
is  necessary  to  ensure  competitiveness  in  Ae  future.  Acre  is  still  Ae  reality  Aat  the  invest¬ 
ment  must  come  out  of  profit.  During  this  time  of  business  contraction,  there  is  prioritizing 
of  what  will  be  done  next.  But  all  m  all,  GEAE  is  continuing  towards  its  goal  of  being  a 
100%  electronically  integrated  enterprise. 


E.23  LOCKHEED  AERONAUTICAL  SYSTEMS  COMPANY  (LASC) 

Industry  1993: 

Business  Strategy: 

Having  won,  with  Boeing  and  General  Dynamics  as  teammates,  the  F-22  Advanced 
Tactical  Fighter  (ATF)  contract  in  mid  1991,  Lockheed  has  made  significant  progress  in  the 
development  and  implementation  of  several  advanced  information  management  systems. 
These  efforts  are  driven  primarily  by  program  requirements,  but  are  also  for  the  general 
benefits  of  enterprise  integration. 

The  Computer  Integrated  Systems,  Technologies,  and  Resources  (CISTAR)  initia¬ 
tive  at  LASC  is  a  company-wide  systems  modernization  effort  to  bring  integrated  product 
development  and  total  quality  management  techniques  to  bear  on  the  functions  of  Engi¬ 
neering,  Operations,  Product  Support,  and  Administration.  TTiese  new  system  applications 
are  being  developed  for  use  on  the  F-22  program  and  subsequently  on  other  programs. 

The  CISTAR  mission  is  to  plan  and  implement  the  transition  from  traditional  orga¬ 
nizationally  compartmentalized,  and  labor-intensive  processes  into  a  seamless  set  of  highly 
automated  systems.  These  systems  will  support  the  goals  of  (1)  reduced  product  costs,  (2) 
reduced  product  development  schedules,  (3)  improved  product  quality,  and  (4)  continuous 
process  improvement  (CPI).  Most  CISTAR  projects  were  in  response  to  F-22  contract 
requirements  and  a  Total  Quality  Management  (TQM)  push  within  the  company. 

CISTAR,  managed  by  a  special  office  within  the  informations  services  and  admin¬ 
istration  line  organization,  has  been  divided  into  five  areas:  integrated  development  sys¬ 
tems,  integrated  production  systems,  integrated  support  systems,  integrated  management 
systems,  and  integrated  information  systems  (Figure  E-4). 

State  of  Integration: 

An  information  technology  standards  committee  has  been  established  within  LASC 
and  is  chaired  by  the  integrated  information  systems  sector  leader.  This  committee  was 
established  in  response  to  high-level  management  frustration  with  the  diversity  and  result¬ 
ing  conflicts  among  standards.  The  standards  committee  tracks  all  Department  of  Defense 
(DoD)  standards  applicable  to  programs  at  LASC,  and  generates  a  preferred  product  list  to 
support  those  standards. 

The  products  to  be  applied  on  the  F-22  program  participants  have  been  mandated. 
A  computer-aided  software  engineering  (CASE)  environment  is  being  established  for  the 
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Figure  E-4.  CIST AR  Architecture 


development  of  general  puipose  software.  This  environment  includes  the  Texas  Instru¬ 
ments  Information  Engineering  Facility  (lEP)  toolset,  the  James  Martin  Information  Engi¬ 
neering  methodology,  and  a  mainframe  encyclopedia  for  information  sharing  and 
management  By  the  end  of  1993,  this  environimnt  will  support  an  IDEF  (ICAM  DEFini- 
tion  Language)  modeling  capability. 

Two  pilot  programs  have  shown  success.  The  first  is  a  materials  database  that  auto¬ 
mates  the  function  of  materials  trade-offs  during  design.  The  second  is  an  automated  shop 
floor  scheduler  that  integrates  the  many  reports  and  sources  of  information  previously  used 
to  manually  generate  those  schedules.  A  third  project,  a  logistics  support  provisioning  tool, 
is  planned  for  1993. 

The  Integrated  Weapons  Systems  Data  Base  (IWSDB),  partially  funded  by  the 
Advanced  Research  Projects  Agency  (ARPA),  is  primarily  funded  by  the  F-22  program. 
The  function  of  this  database  will  be  to  support  the  rapid  solution  of  in-service  problems 
by  making  key  data  available.  The  entire  F-22  program  team,  including  the  subsystem  pro¬ 
gram  office  (SPO)  and  ARPA,  participated  in  the  development  of  a  reference  model  of  the 
F-22,  and  identification  of  the  data  needed  for  the  IWSDB. 


One  of  the  lessons  learned  during  the  first  phase  of  the  IWSDB  project  was  that  a 
paradigm  shift  is  required  when  managing  distributed  program  data  on  heterogenous  sys¬ 
tems.  Problems  are  solved  corroboratively  by  the  program  team  members  connected  by 
electronic  networks,  and  when  data  is  being  managed  firom  a  program-wide  perspective. 

The  IWSDB  will  be  used  to  manage  bodi  business  and  technical  data.  The  IWSDB 
will  provide  SPO  access  to  management  and  schedule  data,  logistics  data,  technical  perfor¬ 
mance  data,  and  some  software  engineering  data.  Most  CDRL  (contract  data  requirements 
list)  data  will  be  developed  electronically.  Training  and  technical  manuals  will  also  be 
available  through  the  IWSDB. 

Most  of  the  design  and  analysis  tools  for  use  on  the  F-22  program  are  on-line  and 
available  team-wide.  These  tools  include  the  following: 

a.  Methods  Improvement  Program  (MIP)  -  an  integrated  computer-aided  analysis 
package. 

b.  Mass  Properties  Estimation  Procedures  (MPEP)  -  an  automated  mass  properties 
calculation  and  reporting  package  [not  yet  available  through  database] 

c.  Lockheed  Advanced  Wiring  System  (LAWS)  -  an  electrical  wiring  system  that 
incorporates  engineering  and  manufacturing  functions. 

d.  Three-Dimensional  Electronic  Mock-Up  (3-D  EMU)  -  a  package  that  provides 
digital  mock-up  capability. 

e.  Design  Support  Database  (DSD)  -  A  database  of  standard  parts,  materials,  and 
documents  and  specifications. 

f.  Direct  Digital  Load  Control  -  a  package  to  support  static  and  fatigue  testing 
using  Direct  Digital  Control  technology  transferred  from  Rye  Canyon. 

g.  Electronic  CDRL  Delivery  System  -  electronic  system  to  access  and  deliver 
CDRL  data  and  provide  access  to  SPO  and  team  partners. 

h.  Electronic  CDRL  Tracking  -  electronic  system  to  track  CDRL  data  and  provide 
access  to  SPO  and  team  partners. 

LASC  does  support  EDI  to  its  major  suppliers.  However,  most  suppliers  still  deliver 
hard  copy  engineering  data  which  is  scanned  into  the  DSD.  In  some  cases  the  reason  for 
this  is  that  suppliers  are  using  different  CAD  systems  than  those  used  at  Lockheed. 

The  integrated  manufacturing  system  group  is  tailoring  existing  systems  to  provide 
an  MRP-2  (manufacturing  resources  planning)  like  system.  It  has  not  yet  automated  the 
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supplier  delivery  of  parts.  LASC  will  evaluate  the  General  Dynamics  acquisition  system  so 
that  there  are  no  overlaps  or  gaps  between  the  two  divisions.  The  General  Dynamics  tool 
for  electronic  sign-off  will  be  used  at  LASC  for  the  F-22. 

Integration  Strategies: 

LASC  is  awaiting  funding  to  proceed  with  the  implementation  of  the  IWSDB. 
LASC  feels  that  efforts  to  integrate  its  information  systems,  processes  and  data  across  the 
enterprise  for  the  F-22  program  must  be  directly  funded  by  the  government. 

LASC  has  decided  not  to  re-engineer  its  legacy  systems  on  a  major  scale,  but 
instead  encapsulate  and  interface  these  systems  to  the  new  IWSDB. 

LASC  may  begin  to  re-engineer  some  of  the  older  business  applications  based  on  a 
good  business  justification.  The  integrated  information  systems  group  has  begun  to  identify 
re-engineering  software  and  procedures  as  a  precursor  to  establishing  a  re-engineering 
environment.  Although  little  benchmarking  has  occurred  to  date,  LASC  plans  to  use  met¬ 
rics  to  perform  trades  among  the  options  available. 

Lessons  Learned: 

Several  years  ago  a  systems  modernization  initiative  was  outlined.  Project  manag¬ 
ers  assembled  cost-benefit  analyses  based  on  the  new  applicable  technologies.  Company 
and  Corporate  management  has  difficulty  accepting  the  cost  justification.  Finally  the  CEO 
stated;  “...enough  done,  it’s  vitally  needed,  can’t  judge  if  it  costs  too  much,  we  must  have 
it.”  LASC  is  now  collecting  data  on  the  cost  savings  it  is  realizing.  Much  of  the  savings  thus 
far  has  been  in  the  area  of  analysis. 

A  big  concern  in  implementing  this  program  is  the  cultural  change  required  by  both 
the  company  and  its  customers  and  suppliers. 

The  develops  tent  of  standards  and  process  and  product  model  descriptions  (e.g., 
PDES,  the  Product  Data  Exchange  Specification)  is  a  major  problem  area.  The  current  gov¬ 
ernment  and  professional  organizations  involved  in  standards  setting  are  moving  much  too 
slowly  to  meet  Lockheed’s  schedules. 

Technology  is  not  a  major  constraint.  Even  though  it  would  like  to  have  the  latest 
hardware  (better  distributed  client-server  systems,  with  mainframes  to  support  CAD  AM/ 
CATIA)  and  software,  LASC  can  “get  by”  with  what  exists. 

Process  definition  and  any  re-engineering  of  those  processes  must  occur  before  any 
attempt  to  automate. 
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Minimal  progress  has  been  made  integrating  suppliers  into  the  enterprise.  Second 
and  third-tier  suppliers  are  often  ignorant  of  Computer-Aided  Acquisition  and  Logistics 
Support  (CALS).  As  yet  this  has  not  been  a  problem  on  the  F-22  program  since  these  sup¬ 
pliers  will  only  really  become  involved  with  the  process  well  after  a  preliminary  design 
review  (PDR).  However,  very  soon,  this  issue  will  have  to  be  finalized.  LASC  managers 
noted  that  waiting  until  the  last  moment  possible  before  informing  suppliers  about  the  data 
delivery  requirements  may  not  appear  to  be  the  best  strategy,  but  data  standards  and  prac¬ 
tices  are  continuing  to  evolve.  It  is  better  to  use  the  latest  and  best  solutions. 

Evolving,  shifting  system  requiren^nts  has  been  a  problem,  contributed  to  be  the 
turnover  of  personnel  on  the  program.  Good  requirements  documentation  is  essential. 

Recommendations: 

Industry: 

Industry  must  share  its  experiences  with  the  standardization  committees  if  useful 
and  timely  standards  are  to  result  Commercial  products  do  not  always  support  standards. 
In  the  case  of  the  F-22,  the  team  has  some  leverage  in  purchasing  products  to  support  its 
effort,  but  it  has  few  choices. 

Government: 

A  common  data  model  is  needed.  LASC  believes  that  a  national  standard  is  required 
and  that  ARPA  should  provide  the  funding  for  this.  LASC  has  a  concern  that  the  numerous 
government  and  commercial  data  model  initiatives  will  not  be  pulled  into  a  common  data 
model,  further  delaying  efficient  EDI. 
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E.24  MARTIN  MARIETTA  MISSILE  SYSTEMS 


Description  of  Business: 

Development,  production,  and  support  to  military  missile  systems. 

Industry  1991: 

Business  Strategy: 

Martin  Marietta  has  a  corporate  strategy  for  enterprise  integration  and  has  a  goal  to 
have  it  in  place  by  1995.  Each  division  is  to  address  local  issues  and  resolve  them  to  the 
best  of  its  ability  while  fulfilling  the  corporate  requirements.  At  the  Missile  Systems  Divi¬ 
sion,  it  has  implemented  several  facets  of  Total  Quality  Management  (TQM)  and  concur¬ 
rent  engineering  and  views  these  as  initial  steps  toward  a  more  complete  enterprise 
integration  implementation. 

State  of  Integration: 

The  major  enterprise  integration  application  is  the  integration  of  the  Mentor  Graph¬ 
ics  and  HP  (Apollo)  computers  into  an  electronic  computer-aided  design  (ECAD)  system 
which  is  electronically  interconnected  to  greatly  enhance  concurrent  engineering  among 
“all”  needed  local  and  dispersed  organizations.  Mechanical  CAD  implementation  has  been 
slower,  having  recently  converted  from  using  CADAM  to  CATIA.  The  LANTERN  program 
is  the  first  to  make  intensive  use  of  these  aspects  of  enterprise  integration. 

Information  Infrastructure: 

The  information  infrastructure  of  the  Printed  Circuit  Board  (PC®)  ECAD  system 
involves  a  network  of  over  100  work  stations,  with  a  fiber  optic  connection  between  facil¬ 
ities  in  Orlando,  Florida,  in  which  the  design  is  produced  and  Ocala,  Florida,  where  the 
PCBs  are  fabricated.  On  one  project  Martin  Marietta  electronically  coupled  PC®  design 
data  with  Texas  Instruments  in  Dallas,  Texas.  The  system  allowed  several  engineers  to  look 
at  the  same  drawing  at  the  same  time.  Electronic  sign-off  of  the  final  design  by  all  involved 
personnel  is  accomplished  within  this  system. 

Martin  Marietta  foresees  the  use  of  animation  (currentiy  using  WAVEFRONT  soft¬ 
ware)  as  one  of  the  next  major  enhancements  in  the  information  interchange  with  the  cus¬ 
tomers,  suppliers,  and  peers. 

With  the  implementation  of  inter-connected  ECAD  system,  Martin  Marietta  has 
attained  significant  cost  savings.  These  include  savings  due  to  a  large  decrease  in  the  num¬ 
ber  of  PCB  drawing  changes.  Changes  declined  from  an  average  of  5  per  drawing  in  1979 
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to  2.2  in  1990,  with  a  goal  of  1.9  within  the  next  few  years.  The  dollar  saving  can  be  calcu¬ 
lated  based  on  a  $5,000  cost  for  each  change  multiplied  by  the  12,000  drawings  created  dur¬ 
ing  1990  and  multiplied  again  the  decreased  average  of  2.8  changes  per  drawing.  This 
equals  $168  million  savings  during  1990.  Other  benefits  were  as  follows: 

•  The  ECAD  system  reduced  the  number  of  design  cycles  it  took  to  produce  a 
PCB  from  2.5  to  1.5. 

•  The  mechanical  CAD  (MCAD)  system  helped  reduce  the  number  of  engineer¬ 
ing  man  hours  to  prepare  the  mock-up  of  the  Patriot  missile  from  2100  hours  to 
900  hours. 

•  The  selection  of  a  better  CAD  support  system  helped  reduce  the  number  of 
CAD  tool  designers  from  10  in  1984  to  4  in  1991. 

•  The  use  of  stereo-lithography  for  preliminary  modeling  (mock-ups)  of  mechan¬ 
ical  parts  from  plastic  has  permitted  engineering  and  management  to  visualize 
the  product  more  quickly  and  at  a  lower  cost  than  when  fabricated  from  wood 
or  metal.  No  cost  or  time  savings  data  was  available. 

A  gross  measurement  of  the  improvement  in  effectiveness  of  the  Martin  Marietta 
work  force  is  noted  by  the  growth  in  total  sales  in  1979  from  $.75  billion  with  15,000 
employees  to  a  1990  sales  of  $2.5  billion  with  8,600  employees. 

Lessons  Learned: 

Martin  Marietta  still  does  not  fully  understand  how  to  best  manage  an  open  archi¬ 
tecture  system.  It  recognizes  that  distributed  processing  is  the  “wave  of  the  future”  and  has 
a  handful  of  pilot  projects  using  the  client-server  architecture  model. 

The  product  description  (PDES)  activities  are  wonderful  but  not  progressing  fast 
enough. 
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NORTHROP  CORPORATION 
Description  of  Business: 

Northrop  is  a  leading  U.S.  aircraft  company,  most  recently  noted  for  its  develop¬ 
ment  of  the  world’s  first  stealth  bomber  aircraft  In  addition  both  commercial  and  fighter 
aircraft  are  produced  at  the  Hawthorne  facility.  Northrop  also  develops  and  produces  mili¬ 
tary  electronic  systems  and  operates  an  information  services  division.  Our  interviews  (both 
the  summer  of  1991  and  spring  of  1993)  were  hosted  by  the  Northrop  Information  Services 
Division  (NISC). 

Industry  1991  and  1993: 

Business  Strategy: 

The  responsibility  for  designing  and  implementing  the  company-wide  enterprise 
integration  efforts  was  given  to  the  NISC  Division.  NISC  management  initiated,  as  an  ini¬ 
tial  enterprise  integration  task,  an  effort  to  define  the  corporation’s  goals,  culture,  business 
interests,  and  best  practices.  As  part  of  this  process,  Northrop ’s  overall  management  also 
identified  what  it  considers  its  core  business  and  expertise.  The  corporate  goals  were  used 
by  the  divisions  to  better  define  their  own  processes,  information  support  requirements, 
technologies,  and  system  concepts.  In  mid- 1991,  Northrop  expected  that  its  enterprise  inte¬ 
gration  program  would  focus  on  the  following  implementation  sequence:  (1)  selection  of  a 
common  process,  (2)  automation  of  the  common  process,  and  (3)  development  of  a  “world- 
class”  process.  One  goal  of  Northrop ’s  enterprise  integration  program  was  to  exchange 
design,  manufacturing,  and  support  information  better  between  the  various  B-2  program 
participants.  As  part  of  the  B-2  program,  Northrop  proposed  establishing  the  Contractor 
Integrated  Technical  Information  Service  (CmS). 

A  new  Division  was  established  for  the  B-2  program.  This  division  brought  engi¬ 
neers  and  managers  firom  across  industry,  and  new  perspectives  (not  all  from  Northrop) 
together.  Integrated  Logistics  Support  (ILS),  normally  in  engineering,  and  Quality  Assur¬ 
ances  (QA),  normally  in  operations  and  manufacturing,  were  both  raised  to  VP-level  func¬ 
tions  to  be  on  a  level  with  engineering. 

State  of  Integration: 

At  the  initiation  of  the  B-2  program,  Northrop  had  several  non-integrated  computer- 
aided  design  (CAD)  systems  in  place.  The  B-2  program  would  involve  many  subcontrac¬ 
tors,  in  addition  to  the  two  other  major  players,  Boeing  and  Vought  Team  members  recog- 
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nized  that  there  were  no  standards  in  place,  and  no  data  release  procedures  among  the 
participants,  and  that  this  would  cause  difficulties  during  the  program.  In  addition,  the  com¬ 
plexity  of  the  B-2  would  provide  severe  manufacturing  challenges  due  to  the  sculpted  sia- 
faces  and  low  observable  requirements.  An  effort  was  begun  to  facilitate  information 
integration,  sharing,  and  control  among  the  B-2  team  members. 

The  first  step  was  the  creation  of  a  single  release  database  to  contain  all  CAD,  part, 
and  ordering  information  at  Northrop.  Duplicate  systems  were  installed  at  Boeing  and 
Vought 

A  network  with  controlled  access  and  encryption  devices  allowed  communication 
and  working  data  set  exchange  among  Northrop,  Boeing,  and  Vought  Security  was  a  major 
concern.  The  major  contractors  installed  secure  voice,  video  teleconferencing,  and  data 
lines.  Due  to  the  costs  of  these  measures,  smaller  subcontractors  did  not  participate  in 
graphics  interchange.  Customers  were  initially  connected  like  small  subcontractors,  but 
will  move  toward  connectivity  more  like  the  larger  contractors. 

The  network  reduced  data  redundancy,  the  primary  cause  of  inconsistencies  among 
engineers.  All  the  information  required  to  run  the  business  was  on-line.  All  engineering 
tools  and  models  and  many  post-processors  were  also  on-line. 

The  single  release  database  permitted  access  to  all  design  data  prior  to  final  release. 
All  downstream  functions,  such  as  logistics,  had  veto  power  over  all  design  releases. 

Using  the  database  and  establishing  a  part-family-oriented  design  t^proach  based 
on  a  significant  modeling  effort,  the  team  developed  an  integrated  manufacturing  process. 
The  part  family  approach  provided  greater  consistency  across  designs  and  allowed  greater 
use  of  automation  in  the  manufacturing  process. 

Initially,  the  three  contractors  had  attempted  to  get  their  CAD  systems  to  work 
together.  This  effort  was  abandon  in  1981.  Instead,  a  common  CAD  system  was  installed 
at  all  three  companies.  This  decision  was  driven  by  the  complexity  of  the  2-D  and  3-D 
design  requirements.  Mechanisms  were  established  to  provide  nightly  synchronization  of 
data  between  the  sites.  Software  was  used  to  ensure  consistency  and  data  integrity  between 
design  changes  at  the  sites. 

A  new  hybrid  job  function  was  created,  tite  data  verification  engineer.  This  position 
encapsulated  the  knowledge  of  a  2-D  and  3-  modeler,  a  manufacturing  engineer,  and  a  data 
modeler. 


Ojiv  ^oal  for  the  B-2  program  was  to  eliminate  waste  in  tooling.  The  approach  was 
to  eliminate  as  much  mock-up  as  possible,  instead  of  driving  tooling  from  models.  The 
results  were  impressive.  All  tubing  was  done  via  models.  The  time  savings  were  used  to 
refine  designs  by  permitting  extra  analyses. 

Information  Infrastructure: 

The  B-2  program  has  exploited  electronic  data  integration  between  the  engineering 
and  manufacturing  departments,  between  Northrop  and  the  Air  Force  B-2  project  office, 
anu,  in  support  of  the  CALS  (Computer-Aided  Acquisition  and  Logistics  Support)  require¬ 
ment,  bc-ween  Northrop  and  the  appropriate  air  logistic  centers  (ALCs).  Within  the  pro¬ 
gram,  Northrop  utilizes  Northrop's  CAD  system  (NCAD),  coupled  to  both  secure  and 
unclassified  T-1  data  lines  for  data  transmission  to  numerous  program  contractors  and  Air 
Force  organizations. 

Utilizing  NCAD,  the  B-2  team  was  able  to  design  and  prototype  (digital  prototype) 
many  parts  of  the  airframe  and  high-performance  avionics  subsystems,  which  led  to  a  per¬ 
fect  fit  on  the  initial-build  vehicle.  This  success  has  led  Northrop  to  adopt  the  goal  of  attain¬ 
ing  \00%  digital  prototyping  on  future  systems. 

The  B-2  contract  was  also  amended  to  include  the  electronic  delivery  of  eleven  con¬ 
tract  data  requirements  list  (CDRL)  items  to  the  B-2  SPO  and  three  ALCs.  This  eliminated 
the  initial  requirement  for  hard-copy  delivery  of  the  items.  The  electronic  interchange  has 
led  to  a  much  closer  interaction  of  the  parties  involved  in  the  B-2's  development,  and  thus 
many  of  the  problems  that  would  not  have  surfaced  until  later  in  the  program’s  life  cycle 
surfaced  early  and  were  solved.  Early  problem  resolution  in  this  case  is  a  clear  but  undoc¬ 
umented  cost  savings. 

Unfortunately,  the  goal  of  the  B-2  program  was  to  build  a  unique,  state-of-the-art 
bomber  aircraft  at  the  lowest  possible  cost,  not  to  document  the  advantages  of  enterprise 
integration.  However,  one  metric  that  was  brought  to  light  was  that  the  use  of  enterprise 
integration  reduced  the  time  to  get  approval  on  a  provisioning  document  from  6  months  to 
60  minutes.  This  was  a  result  of  both  Northrop  and  Air  Force  personnel  being  electronically 
linked  and  interacting  as  the  document  was  prepared. 

B-2  ems 

Due  to  the  success  and  obvious  savings  resulting  from  the  use  of  enterprise  integra¬ 
tion  on  the  B-2  program  (delivery  of  CDRLs,  communicating  with  suppliers  and  the  Air 
Force,  communicating  between  facilities  within  Northrop),  Northrop  proposed  to  develop 
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and  implement  a  B-2  program-wide  electronic  information  system,  the  CITIS.  The  B-2 
SPO  funded  a  business  case  feasibility  study  on  CITIS  whose  results  were  published  in 
August  1992.  The  study  looked  at  a  number  of  data-driven  services  and  processes  whose 
cycle  time  could  be  dramatically  reduced,  thus  resulting  in  costs  savings  over  the  current 
business  practice.  Some  of  the  savings,  such  as  those  associated  with  the  storage  of  design 
data,  were  actual  savings  documented  within  the  current  B-2  program;  others  were  esti¬ 
mates  of  future  cost  savings  that  could  be  realized  if  CITIS  were  implemented. 

Estimated  cost  savings  were  developed  for  four  levels  of  CITIS  involvement  (each 
level  representing  a  broader  application  of  electronic  integration).  Based  on  the  Northrop- 
generated  study,  the  potential  cost  savings  (cost  savings  and  cost  avoidance)  from  CITIS 
on  the  B-2  programs  ranged  from  a  total  of  $537  million  to  $894  million  over  the  life  cycle 
of  the  initial  B-2  buy  depending  upon  the  level  of  CITIS  involvement.  TTie  analyses  also 
included  savings  resulting  from  reduced  acquisition  time  and  shortened  supply  pipelines. 

Lessons  Learned: 

Based  on  its  B-2  experience,  Northrop  anticipates  the  greatest  barriers  to  enterprise 
integration  will  be  the  internal  resistance  to  cultural  changes.  On-line  access  to  information 
proved  to  be  a  new  way  of  doing  business  to  some.  Experience  showed  that  it  was  best  not 
to  force  people  to  go  on-line  if  they  resisted.  Electronic  sign-off  was  accepted  by  some 
groups  and  not  others.  For  instance,  the  structural  engineering  group  still  wanted  a  paper 
sign-off. 

Additionally,  there  is  the  cultural  change  that  must  also  take  place  within  the  cus¬ 
tomer  (Air  Force)  environment.  While  the  Air  Force  SPO  regarded  the  electronic  inter¬ 
change  of  data  as  a  positive  action,  it  also  came  to  the  realization  that  the  required  specified 
level  of  detail  regarding  protocols,  format,  and  data  was  far  more  extensive  than  originally 
expecua 

Significant  procedural  changes  were  also  required  for  the  B-2  program.  A  model¬ 
ling  guide  was  developed  to  define  the  rules  for  modeling  parts  to  be  included  in  the  part 
family.  A  multi-discipline,  on-line  release  and  change  process  was  established.  This  release 
process  eliminated  the  problem  of  engineers  developing  finely  detailed  3-D  models  before 
releasing  them  to  the  community  for  comment  and  feedback.  Engineers  now  allow  earlier 
sharing  of  design  information. 

Common  systems  were  necessary  to  enable  team  interaction  and  cooperation.  Soft¬ 
ware  compatibility  was  required  for  data  portability.  Northrop  is  now  trying  to  de-couple 
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data  from  the  NCAD  tool  used  to  create  it.  The  goal  is  to  move  toward  an  open  system  in 
the  future,  eliminating  the  need  to  maintain  a  CAD  tool  for  life. 

Some  of  the  benefits  derived  from  the  integration  efforts  on  the  B-2  program 
include  the  following: 

•  6: 1  form  and  fit  error  reduction. 

•  17:1  error  reduction  in  tubing.  97%  yield  in  first  time  tubing. 

•  5:1  improvement  in  producability  change  incorporation. 

•  40%  reduction  in  NC  (numerical  control)  programming  effort. 

•  475,000  hours  avoided  in  the  last  24  months  to  perform  mass  updates  of  draw¬ 
ings  and  parts  lists. 

•  $2.4  million  in  savings  in  travel  costs  due  to  teleconferencing. 

•  $20  million  in  costs  avoided  to  date  with  on-line  provisioning. 

•  Drawing  cycle  time  reduced  from  55  people  days  (pre-B-2  program)  to  7  people 
days. 

•  Decreased  shop  floor  paper  and  instructions  22,000  pages  per  vehicle  with  an 
on-line  IMPCA  (Integrated  Manufacturing,  Planning,  Control,  and  Assembly) 
system  with  graphics. 

Industry  2001: 

Vision: 

The  B-2  experience  has  convinced  Northrop  that  enterprise  integration  is  the  only 
practical  way  to  go  for  the  future.  The  technology  exists  for  enterprise  integration.  Cultural 
and  organizational  changes  are  needed  however.  The  extent  that  enterprise  integration  is 
implemented  will  be  a  function  of  its  business  environment,  customer  base,  and  the  status 
of  its  internal  business  processes.  Two  areas  that  need  additional  attention  are  change  man¬ 
agement  and  configuration  control. 

Recommendations: 

Government: 

In  order  to  exploit  the  benefits  of  enterprise  integration,  the  SPO  will  have  to  be  bet¬ 
ter  prepared  to  receive,  process,  and  act  upon  data  in  an  electronic  format.  This  include 


updating  the  electronic  receiving  and  processing  equipment,  being  prepared  to  process  data 
electronically,  and  the  training  of  SPO  staff  to  function  within  the  enterprise  integration 
environment. 

Federal  Acquisition  Regulations  (PARS),  including  Defense  (DARS),  Navy 
(NARS),  Air  Force  (AFARS),  which  restrict  the  use  of  program  funds  to  upgrade  SPO  com¬ 
puter  equipment  should  also  be  changed. 

The  questions  of  how  to  charge  the  government  for  information  and  the  mainte¬ 
nance  of  the  databases  containing  the  information  have  been  not  resolved. 
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E.26  UNITED  TECHNOLOGIES  -  PRATT  AND  WHITNEY 
Description  of  Business 

Pratt  and  Whitney  is  one  of  two  U.S.  manufacturers  of  large  gas  turbine  engines.  Its 
product  line  spans  the  commercial  market’s  requirement  for  all  large  turbofan  engines  and 
the  military’s  requirement  for  high  performance  turbojets  through  heavy  lift  cargo  aircraft 
turbo  fan  engines  and  smaller  high  technology  fighter  aircraft  engines. 

Commercial  engine  development  and  production  is  centered  in  the  Hartford,  Con¬ 
necticut,  locale,  and  it  is  from  here  that  its  world-wide  engine  logistic  support  network  for 
all  commercial  aircraft  operators  originates. 

Pratt  and  Whitney’s  military  aircraft  development  and  production  activities  are  cen¬ 
tered  in  West  Palm  Beach,  Florida.  Pratt  and  Whitney  designs  and  produces  some  of  the 
most  efficient  and  sophisticated  large  military  fighter  aircraft  engines  in  the  world.  The  sep¬ 
arate  military  and  commercial  development  facilities  accommodates  the  need  for  address¬ 
ing  commercial  and  military  contractual  accounting  requirements  as  well  as  enforcing  DoD 
security  requirements. 

Industry  1993: 

Business  Strategy: 

Pratt  and  Whitney  made  the  decision  that  it  was  going  to  do  whatever  was  necessary 
to  enhance  its  image  as  a  world  class  supplier  of  commercial  aircraft  engines  to  its  world¬ 
wide  customer  base  of  commercial  aircraft  operators  (about  350  airlines).  An  internal  anal¬ 
ysis  of  the  company’s  business  dealings  with  its  customers  as  well  as  customer  interviews 
revealed  that  Pratt  and  Whitney  had  developed  a  serious  credibility  problem  with  its  cus¬ 
tomer  base.  Engine  problems  were  taking  too  long  to  resolve,  many  problems  were  not 
being  addressed  because  the  problem  did  not  peak  somebody’s  interest,  and,  when  prob¬ 
lems  were  forced  into  the  limelight  by  an  engine  user,  solutions  were  tiger-teamed  to  the 
detriment  of  other  ongoing  problem  solutions.  The  bottom  line  was  that  customer  problem 
solving  was  preventing  Pratt  and  Whitney  from  filling  the  world  class  supplier  role  it  envi¬ 
sioned  for  itself. 

State  of  Integration: 

Pratt  and  Whitney’s  management  recognized  that  it  had  developed  a  smokestack 
mentality  to  data  management  and  flow  when  in  reality  a  horizontal  data  flow  was  needed. 
Pratt  and  Whitney  embarked  upon  an  enterprise  integration  program  which  will  eventually 
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encompass  all  of  the  company’s  business  activities,  both  internal  and  external.  To  support 
its  enterprise  integration  activities,  Pratt  and  Whitney  undertook  an  extensive  data  manage¬ 
ment  restructuring  program  entitled  Vision  2000,  to  serve  as  the  primary  facilitator  for  all 
enterprise  integration  activities,  data  base  conversions,  updates,  and  distributed  data  man¬ 
agement  plans. 

Pratt  and  Whimey’s  management  established  Integrated  Product  Management 
Teams  (IPMT)  composed  of  operational  managers  for  each  major  product  (e.g.,  the  4000 
engine).  These  teams  meet  weekly  to  review  and  take  action  on  major  problems  associated 
with  their  product  (i.CM  PW  4000).  There  are  10  to  1 2  Component  Integrated  Product  Teams 
(OPT)  under  each  IPMT,  one  for  each  engine  major  subsystem  or  section  (turbine,  com¬ 
pressor,  etc.).  Membership  includes  the  leaders  of  the  various  groups  involved  in  the  com¬ 
ponent  area  (engineering,  manufacturing,  quality,  etc.).  The  ClPTs  also  meet  weekly. 
Reporting  to  the  CIPTs  are  about  100  Integrated  Product  Teams  (IPTs),  one  for  each  Pratt 
and  Whitney  subcomponent  or  problem  part  found  in  the  component  (next  higher  assem¬ 
bly).  IPTs  are  formed  for  each  newly  designed  part  or  as  problems  arise,  meet  as  necessary, 
and  disband  when  their  job  is  finished.  If  a  problem  occurs  with  their  part  in  the  future,  the 
same  people  reconvene.  The  total  framework  of  IPMT/CIPT/IPT  makes  up  Pratt  and  Whit¬ 
ney’s  Integrated  Product  Development  process  or  ff  D.  The  enterprise  integration  data  man¬ 
agement  system  has  been  designed  to  support  the  IPD  process. 

At  about  the  same  time  that  the  IPD  process  was  being  established.  International 
Aero  Engines  (lAE),  a  joint  venture  between  Pratt  and  Whimey,  Rolls  Royce,  MTU 
(Motoren  -  und  Turbinen-Union),  Fiat,  and  Japan  Aero  Engine  Company  (JAEC)  put  an 
Request  for  Proposal  (RFP)  on  the  street  to  develop  a  problem-tracking  system.  The  Vision 
2000  group  bid  and  won  the  contract  TTie  product  VECTORS  (V25(X)  Engineering 
Change  Tracking  and  Online  Reporting  System),  built  on  top  of  IBM’s  Product  Manager, 
served  as  the  development  vehicle  for  the  IPD  project  (VECTORS  is  an  electronic  folder 
system  that  incorporates  all  the  data  on  a  problem  previously  collected  in  paper  format  into 
a  single  electronic  folder  for  each  problem.) 

lAE  initiated  the  VECTORS  project  because  it  was  spending  $1.5  million  a  year 
faxing  problems,  change  orders,  and  configuration  control  documents  around  the  world  to 
its  partners.  Since  VECTORS  has  been  installed  on-line,  lAE  costs  for  the  same  informa¬ 
tion  control  and  transmittal  has  dropped  to  $10,(XX)  per  month  for  CPU  charges  ($120,000 
per  year).  Program  problems  under  the  paper-fax  system  averaged  100  days  from  entry  into 
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the  system  until  close-out.  Under  the  VECTORS  electronic  folder  control  system,  average 
time  was  reduced  to  less  than  20  days. 

Another  interesting  fact  that  emerged  at  lAE  with  the  conversion  from  the  paper 
tracking  system  to  VECTORS  was  that  only  1,250  active  problem  solving  programs  were 
identified  whereas  the  paper  tracking  system  showed  about  1,700  problems  being  worked 
in-house.  The  reason  was  that  under  the  paper  tracking  system,  once  problems  were  logged 
in,  about  450  problems  were  never  addressed  and  therefore  were  not  picked  up  by  VEC¬ 
TORS.  VECTORS  now  tracks  100%  of  the  customer  and  product  problems  at  lAE. 

With  this  experience,  the  VISION  2000  project  office  started  the  development  of  a 
series  of  electronic  folders  to  support  the  IPD  process. 

The  first  product  was  the  Common  Problern/Task  Report  (CPTR)  folder  which 
came  on-line  in  June  1992.  The  project  started  as  a  result  of  customer  dissatisfaction  with 
the  way  problems  were  solved.  Its  need  was  reinforced  when  Boeing  insisted,  contractually, 
that  Pratt  and  Whimey  have  a  problem  tracking  system  in  place  for  all  777  work;  a  second 
project,  the  CPTR  folder,  was  conceived.  It  was  originally  thought  that  the  PW2000  engine 
program  would  be  the  first  Pratt  and  Whitney  program  to  use  and  prove  the  CPTR  folder 
concept  It  is,  however,  actually  being  exploited  by  the  PW4000  engine  program  (the  111 
commercial  engine  program)  which  currently  has  about  1 ,000  problems  under  active  track¬ 
ing.  An  Integrated  Product  Team  (IPT)  folder  is  initiated  at  the  IPT  level  to  complete  and 
track  engineering  change.  This  is  done  when  the  IPT  is  formed.  Into  it  are  recorded  all  data 
required  to  track  actions  taken  by  the  IPT  (problem  definition,  design  changes,  solution, 
owner  of  solution,  etc.),  and  the  folder  serves  as  an  up-to-date  living  electronic  document. 
All  folders  are  cunently  on  a  mainframe  but  the  move  is  to  switch  firom  the  main  frame  to 
a  fully  distributed  system. 

When  a  product  problem  is  identified  in  test  or  in  the  field,  a  CPTR  folder  is  estab¬ 
lished  at  the  IMPT  or  CIPT  level.  This  forces  the  establishment  of  an  IP  team  to  solve  the 
problem  and  an  IPT  folder  to  record  all  actions  taken.  The  CPTR  becomes  the  controlling 
document  for  its  respective  IPT  folder. 

Pratt  and  Whitney’s  internal  design  system  of  choice  is  Unigraphics  for  all  solids 
modeling  because  it  lends  itself  to  a  distributed  system.  It  is  also  going  toward  extensive 
use  of  Sun  workstations.  Boeing  had  insisted  that  Pratt  and  Whitney  use  CATIA  for  all  111 
work.  Pratt  and  Whitney  resisted  but  did  agree  to  develop  a  Unigraphics-CATIA  translator 
with  Unigraphic’s  assistance.  It  currently  has  about  2,400  workstations  on-line  in  Pratt  and 
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Whitney  plus  about  13,000  personal  computers.  In  turn,  Pratt  and  Whitney  insisted  that  all 
Tier  1  suppliers  deliver  their  designs  in  CATIA  or  Unigraphics.  Pratt  and  Whitney  is  help¬ 
ing  its  suppliers  move  to  a  workstation  environment  by  selling  them  Pratt  and  Whitney’s 
old  workstations  and  computers  at  discounted  rates,  assisting  in  the  training  of  the  people, 
and  covering  them  under  Pratt  and  Whimey’s  software  site  licenses.  One  of  the  payoffs  is 
the  ability  (also  a  contractual  requirement)  to  undertake  electronic  prototyping.  In  fact, 
Boeing  has  required  that  all  777  engine  mock-ups  be  electronic. 

Pratt  and  Whitney  currently  has  60,000  active  design  files.  There  are  500,000  old 
designs  on  file.  The  active  files  will  be  put  onto  Unix  woricstations.  The  old  files  will  be 
installed  when  and  if  they  are  used:  if  conversion  is  justified  and  metadata  is  provided.  The 
engineer  will  have  the  option  of  viewing  the  object  in  the  system  using  FORMTEK,  or  by 
building  a  Unigraphics  object-oriented  file.  This  decision  will  be  made  on  a  case-by-case 
basis. 

In  parallel  with  the  design  automation  process,  Pratt  and  Whitney  has  reduced  its 
supplier  base  by  over  50%,  from  about  800  to  about  3(X)  suppliers.  Pratt  and  Whitney  would 
like  to  go  to  a  single  source  for  many  of  its  items,  but  in  turn  would  like  to  establish  a 
shared-risk  arrangement  with  its  suppliers. 

Pratt  and  Whitney  is  working  on  a  Distributed  Data  Management  (DDM)  system. 
One  of  the  goals  is  to  ensure  that  all  who  are  required  to  work  with  engineering  or  design 
data  are  working  with  the  latest  information.  While  not  documented,  Pratt  and  Whitney 
estimates  that  up  to  10%  of  current  engineoing  hours  might  be  wasted  hours  because  a 
solution  or  design  change  is  generated  by  an  engineer  using  his/her  own  outdated  data  base. 
When  discovered,  corrections  are  made,  of  course,  but  the  fact  is  not  made  known.  Pratt 
and  Whitney  has  retrained  all  its  engineers  to  use  workstations  and  Unigr^hics,  but  is  still 
tied  to  the  mainframe  to  manage  all  its  data.  The  goal  is  to  move  to  distributed  servers  and 
allow  information  sharing  by  maintaining  only  the  metadata  on  the  mainframe.  By  the 
fourth  quarter  of  1 993,  Pratt  and  Whitney  will  have  all  the  drafting  groups  using  shared  data 
(having  provided  the  metadata  needed).  This  new  way  of  doing  business  will  ensure  that 
anyone  who  requests  information  will  always  receive  the  most  recent  information  avail¬ 
able.  Drawings  will  be  released  in  one  of  several  forms,  paper  (raster  images),  vector  graph¬ 
ics,  or  solid  models. 

An  interesting  metric  on  the  cost  savings  available  when  moving  from  a  mainframe- 
based  data  management  system  to  a  distributed  system  is  that  Pratt  and  Whitney  was  able 
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to  reduce  the  backup  costs  from  $105.00  per  user  per  month  to  $18.00  per  user  on  the  dis¬ 
tributed  system. 

Documenting  the  configuration  of  developmental  engines  is  a  serious  problem.  In 
the  past,  the  commercial  side  of  Pratt  and  Whitney  exercised  much  less  control  over  test 
engine  configuration  than  the  military  side  of  the  house.  All  configuration  tracking  was 
paper-based  and  would  lag  behind  the  engine  build-up  (and,  unfortunately,  frequently  the 
teardown).  Pratt  and  Whitney  is  going  to  DECMACS  (Development  Engine  Change  Man¬ 
agement  and  Control  System).  As  of  February  1993, 85%  of  the  software  development  was 
complete.  DECMACS  will  be  used  initially  on  the  FI  1 9  and  PW40(X)  engine  programs.  As 
an  example  of  how  serious  this  problem  can  be,  upwards  of  600  engineering  changes  take 
place  on  each  test  engine.  Under  the  current  system,  many  minor  changes  go  unrecorded. 
DECMACS  is  intended  to  change  this  by  providing  electronic  change  control  as  the  engine 
is  built. 

Internally,  Pratt  and  Whitney  figures  that  it  has  about  28  bills  of  material  (BOM) 
and  between  75  to  80  change  management  systems.  For  example,  each  department  has  its 
own  change  management  system  for  each  Pratt  and  Whitney  product.  The  tie-in  required 
by  the  CPTR  and  IPT  folders  to  a  strong  change  nnd  configuration  management  system  will 
erode  the  feasibility  for  local  (departmental)  change  management  systems,  thus  forcing  the 
phase-out  of  the  local  systems. 

Issues  and  Barriers: 

As  elsewhere,  the  major  impediment  to  change  is  found  in  the  people.  For  some,  it 
is  the  need  to  change  a  work  culture,  for  others  it  is  the  need  to  accept  the  fact  that  what 
they  have  been  doing  for  many  years  is  no  longer  the  best  way,  and  in  fact,  may  no  longer 
be  needed  or  wanted.  The  change  in  the  way  the  business  process  is  to  be  managed  is  also 
an  impediment.  New  business  processes  and  practices  require  new  management  processes. 
Fortunately,  Pratt  and  Whitney’s  enterprise  integration  and  data  management  changes  are 
being  championed  from  the  top-down  and  implemented  from  the  bottom-up. 

Industry  2001: 

Pratt  and  Whitney’s  goal  is  to  strive  for  a  paperless  environment  where  it  makes 
sense,  both  from  a  fiscal  and  practical  point  of  view.  Realistically,  it  knows  this  will  not 
happen  for  quite  some  time  due  to  the  nature  of  its  customer  base.  For  example,  Pratt  and 
Whitney  is  currently  on  line  electronicaUy  with  United  Air  Lines.  But  there  are  many  small 
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airline  carriers  within  the  Pratt  and  Whitney  customer  base  of  350  who  will  not  be  able  to 
afford  to  go  electronic  for  many  years,  and  in  some  cases  never. 


There  are  also  discussions  of  single  point  management  of  spares  inventories 
between  engine  operators,  overhaul  centers,  and  Pratt  and  Whitney.  Such  information  will 
allow  major  suppliers  like  Pratt  and  Whitney  to  plan  production  runs  and  supplier  buys  far 
enough  in  advance  to  optimize  production  quantities  and  schedules  for  cost  breaks. 

Is  it  worth  the  investment?  Pratt  and  Whitney  thinks  so.  For  example,  the  CPTR  and 
IPT  folder  concept  alone  is  estimated  to  decrease  product  development  and  problem  solu¬ 
tion  time  by  at  least  10  to  15%.  When  fully  implemented  across  Pratt  and  Whitney,  this  will 
translate  into  a  $60  million  per  year  savings.  The  Vision  2000  project,  IPT,  CPTR, 
DECMACS,  etc.,  is  currently  costing  $6  million  per  year. 
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APPENDIX  F.  FRAMEWORKS 


The  word  “framework”  is  in  vogue,  being  used  by  organizations  to  refer  to  their 
respective  approaches  for  enabling  interoperation  among  software  products.  To  provide 
some  focus  and  precision  for  this  study,  we  introduce  the  term  “operational  integration 
framework”  and  give  its  definition  in  Section  F.l. 

In  particular,  software  makes  up  a  very  large  and  growing  portion  of  engineered 
products,  and  of  Department  of  Defense  (DoD)  acquisitions.  Operational  integration 
framework  standards  for  software  engineering  environments  will  help  control  the  costs  of 
software  products.  In  Section  F.2,  we  describe  activities  in  the  software  engineering  com¬ 
munity  to  develop  Software  Engineering  (CASE,  computer-assisted  software  engineering) 
Frameworks. 


F.l  OPERATIONAL  INTEGRATION  FRAMEWORKS 

“Framework”  is  used  to  describe  many  different  concepts  and  kinds  of  things.  In 
most  cases,  these  descriptions  are  legitimate:  they  share  some  conunon  basis  reasonably 
attributable  to  the  word.  Unfortunately,  these  descriptions  also  differ  in  some  very  funda¬ 
mental  ways  and  the  differences  are  often  unstated,  causing  confusion.  This  section  con¬ 
tains  a  proposal  for  defining  a  specific  use  of  the  word.  To  make  the  difference  explicit,  the 
term  “operational  integration  framework”  will  be  used. 


F.1.1  DEFINITIONS 

An  operational  integration  framework  (OIF)  is  a  collection  of  executable  software. 
The  OIF  is  a  skeletal  part  of  an  operational  information  and  process  management  system, 
and  provides  a  set  of  services  and  data  types  common  across  all  information  systems  based 
on  the  OIF.  The  OIF  is  used  by  human  users  and  other  software  (tools  and  agents)  to  struc¬ 
ture  and  manage  information,  coUections  of  software  tools,  and  collections  of  external  pro¬ 
cesses  in  an  integrated  fashion  such  that: 

a.  The  actual  information  being  managed  may  be  inserted  into  the  OIF  but  is  not 
actually  part  of  the  framework; 
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b.  The  framework  manages  information  and  metadata  about  the  information — that 
is,  it  manages  the  information  model  which  the  user  organization  detines; 

c.  The  actual  software  tools  (a  broad  term)  being  managed  may  be  inserted  into 
the  OIF  but  are  not  actually  pan  of  the  framework; 

d.  The  framework  manages  metadata  about  the  tools; 

e.  Models  of  processes  to  be  managed  are  inserted  into  the  OIF  but  are  not  actually 
pan  of  the  framework; 

f.  The  framework  provides  process  control  mechanisms  so  that  actions  can  be 
triggered  on  the  occunence  of  events  defined  in  the  process  model; 

g.  The  framework  implements  definitions  of  how  information,  tools,  and  models 
may  be  inserted  into  it  and  it  provides  mechanisms  for  controlling  that  insertion; 
and 

h.  The  framework  provides  mechanisms  for  the  enforcement  of  policies  concern¬ 
ing  information  and  tool  use  (perhaps  a  subset  of  item  /),  and  mechanisms  for 
the  expression  of  such  policies  and  insertion  of  them,  but  the  policies  them¬ 
selves  are  defined  by  the  user-organization. 

Thus,  the  information  and  process  management  system  that  an  organization  uses 
will  be  made  up  of  an  OIF  fil  d  in  with  tools,  information  and  process  models,  information 
bases,  and  policies.  Two  systems  operated  by  different  organizations  that  are  based  on  the 
same  OIF  might  contain  different  kinds  of  tools  and  information,  different  tools  or  infor¬ 
mation  of  the  same  kind,  or  identical  tools  and  information.  Having  the  same  OIF,  they 
would  have  the  same  notion  of  “kind”  and,  therefore,  they  would  be  able  to  exchange  infor¬ 
mation  of  the  same  kind  and  the  systems  would  know  that  they  are  of  the  same  kind 
(because  of  conventions  on  metadata).  Furthermore,  communities  of  interest  would  have  a 
base,  the  OIF,  in  which  to  implement  conventions  on  information  representation,  service 
intrafaces,  and  kinds  of  policies  (e.g.,  configuration  management),  and  would  know  that 
these  conventions  were  enforceable  on  their  systems  through  the  mechanisms  of  their  com¬ 
mon  OIF.  All  these  are  intended  to  follow  from  the  definition. 

Note  that  there  are  desirable  characteristics  of  OIFs  not  listed  above.  One  example 
might  be  that  the  information  structuring  and  metadata  allowed  must  support  strong 
abstract  type  mechanisms.  Another  might  be  dtat  policies  must  be  expressible  as  rules.  It 
may  well  be  that  some  of  these  desirables  will  be  defined  in  any  official  standard  OIF.  For 
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the  purposes  of  understanding  the  concept  and  utility  of  OIF,  they  are  not  necessary.  Note 
also  that  the  definition  could  have  been  built  by  defining  operational  framework,  then  add¬ 
ing  the  characteristics  having  to  do  with  integration  support. 

F.l^  RELATIONSHIP  TO  “ARCHITECTURE” 

The  word  “architecture”  is  commonly  used  in  the  information  management  com¬ 
munity  in  at  least  three  ways  that  derive  from  general  use. 

First  and  most  basic,  is  the  “architecture  process”;  what  architects  do.  Architects 
create  designs  or  models  of  things  to  be  built  In  the  information  world,  these  may  be  mod¬ 
els  or  designs  that  try  to  describe  either  functional  or  structural  characteristics  of  the  thing 
to  be  built 

Second,  is  the  “product  of  the  architecture  process”:  architectures.  These  are,  as 
indicated  above,  designs  or  models  of  things  to  be  built.  Since  all  proper  models  are 
abstracted  from  reality  (where  “proper”  is  in  the  set  theoretic  sense),  they  always  leave  out 
details.  In  information  systems,  architectures  usually  are  designs  that  have  significant  num¬ 
bers  of  significant  details  left  abstract.  These  absent  details  are  often  called  “implementa¬ 
tion  details.”  The  failure  of  many  system  implementations  gives  rise  to  some  speculation 
about  this  partitioning  of  the  design  problem;  it  must  be  done  very  carefully.  On  the  other 
hand,  a  high-level  design,  or  architecture,  is  oi^n  needed  to  understand  the  general  shape 
of  a  system  to  be  built  and  to  make  some  general  or  high-level  decisions  about  it.  The  pres¬ 
ence  of  all  the  details  might  make  this  understanding  impossible  and  their  absence  may 
make  the  decisions  wrong.  This  is  probably  the  fundamental  problem  of  doing  multi-level 
design. 

The  third  meaning  of  architecture  follows  from  the  second  and  it  has  to  do  with  the 
“high-level  characteristics  of  designs.”  Thus,  a  system  with  a  “client-server  architecture” 
is  one  that  has  certain  structures  with  certain  behaviors  and  interrelationships — similarly,  a 
“cyclically  scheduled  architecture”  or,  arguably,  a  “RISC  architecture”  (Reduced  Instruc¬ 
tion  Set  Computer). 

In  this  third  sense,  one  could  describe  some  systems  as  having  a  “framework-based 
architecture.”  A  system  based  on  an  OIF  would  be  of  this  class.  Thus,  an  OIF  is  an  archi¬ 
tectural  entity  because  it  is  a  fundamental  and  obvious  structural  entity  within  a  system  and 
would  be  described  as  such  in  the  architecture  (second  meaning)  of  the  system.  The  archi¬ 
tect,  doing  architecture  (first  meaning),  would  have  to  decide  early  on  that  the  system 
would  be  based  on  an  OIF. 
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There  is  also  an  obvious  connection  between  “architecture”  and  OIF  in  the  other 
direction.  An  OIF  is  a  thing  to  be  built.  It  must  be  designed.  It  is  complicated  enough  to 
require  a  high-level  design,  an  architecture  (second  meaning).  In  fact,  for  the  purposes  of 
standardization,  the  architecture  may  be  all  that  is  needed.  (It  may  be  that  the  standardiza¬ 
tion  will  proceed  at  greater  depth  in  some  areas  of  the  OIF  design,  though.) 

F.1.3  OPPORTUNITY  FOR  STANDARDIZATION 

The  utility  of  OIF  was  expressed  above  in  terms  of  conununity  interactions.  This 
community  might  be  made  up  of  organizations  within  a  company  or  of  organizations  from 
several  companies  teaming  to  design  and  build  a  product  In  either  case,  there  is  an  eco¬ 
nomic  payoff  in  having  a  standard  OIF.  There  is  a  reasonable  level  of  understanding  of  the 
concept  in  the  conununity  of  potential  suppliers  of  OIF  products  and  of  tool  vendors  who 
would  build  to  OIF-specified  interfaces.  There  is  even  reasonable  understanding  of  how  to 
deal  with  legacies.  And  there  are  some  demonstration  products.  It  happens  that  these  prod¬ 
ucts  have  some  but  not  overwhelming  market  penetration,  and,  therefore,  the  interface 
specification  situation  has  not  yet  gotten  out  of  control.  There  is  an  opportunity  now  to  start 
the  standardization  process  in  earnest  There  will  have  to  be  continuing  demonstrations  of 
various  approaches  both  to  settle  some  issues  and  to  demonstrate  utility  in  real  projects. 
These  demonstrations  will  also  educate  the  community  on  the  necessary  support  structures. 
Nevertheless,  the  standardization  process,  focused  on  an  OIF  approach  to  integrated  infor¬ 
mation  and  process  management,  is  now  feasible. 

F.1.4  OPERATING  SYSTEM  OF  THE  FUTURE? 

The  similarities  between  OIF  and  the  notion  of  operating  system  are  pretty  obvious. 
Operating  systems  manage  memory,  manage  internal  (computer)  processes,  manage  input/ 
ouqjut  (I/O)  resources,  run  the  file  system,  and  perhaps  a  few  other  things.  Some  of  these 
functions  can  be  modularized  (operating  systems  used  to  be  conceived  as  including  the  user 
interface).  If  the  world  began  using  OIF-based  systems,  eventually  unneeded  modules  of 
what  we  now  call  operating  systems  would  be  cast  away.  A  micro  kernel  might  be  all  that 
is  needed  and  would  produce  maximum  performance.  The  OIF  might  be  the  operating  sys¬ 
tem.  Evidence  of  a  trend  in  this  direction  can  be  found  in  the  widespread  use  of  Microsoft 
Mndows,  which  provides  inter-tool  services  to  tools  on  a  simulated  desktop,  similarly  the 
Apple  Macintosh  operating  system,  and  the  reported  work  on  joint  development  of  an 
object-oriented  operating  system  by  Apple  and  IBM. 


SOFTWARE  ENGINEERING  (CASE)  FRAMEWt  RKS 

The  software  engineering  community  is  developing  sophisticated  operational 
frameworks  for  the  integration  of  software  engineering.  This  section  describes  some  of  the 
efforts  in  order  to  give  the  reader  a  feel  for  the  kinds  of  activities  happening  in  the  devel¬ 
opment  of  potential  standards  for  operational  frameworks  in  one  community.  * 

¥2. 1  DEnNITIONS  AND  TERMS 

The  term  “framework”  has  been  used  in  several  ways.  For  CASE  environments, 
“framework”  is  generally  accepted  to  refer  to  a  set  of  common  services,  found  in  all  envi¬ 
ronments,  and  callable  by  an  ad  hoc  tool  that  is  introduced  to  the  environment.  The  Nation- 
al  Institute  of  Standards  and  Technology  (NIS'O  Reference  Model,  based  on  earlier  work 
done  by  the  European  Computer  Manufacturers  Association  (ECMA),  has  been  widely 
accepted  throughout  the  CASE  community.  Its  definition  of  “framework”  is  generally 
accepted  as  definitive: 

Current  thinking  in  the  area  of  CASE  environments  is  that  an  environments 
consists  of  a  (relatively)  fixed  set  of  core  facilities  which  form  the  “Environ¬ 
ment  Framework,”  and  a  set  of  facilities,  called  “Tools,”  which  are  more 
specialized  for  particular  environments  and  cannot  be  presumed  to  be  avail¬ 
able  in  all  environments.  Tools  use  the  services  provided  by  the  environ¬ 
ment  framework  to  a  large  extent,  and  as  integration  mechanisms  evolve 
over  time,  this  will  increase . . .  Services  in  one  part  of  the  framework  may 
use  services  in  other  parts  of  the  framework. 

The  NIST  Reference  Model  defines  the  following  categories  of  framework  services:  Object 
Management,  Task  Management,  Communication,  User  Interface,  Tool  Integration,  Secu¬ 
rity,  and  Framework  Administration/Configuration. 

Central  to  most  descriptions  of  a  framework,  including  the  NIST  model,  is  the  sup¬ 
position  that  the  framework  is  an  integrating  agent.  Three  forms  of  integration  are  com¬ 
monly  assumed:  data  integration,  control  integration,  and  presentation  integration.  In  the 
NIST  model,  the  first  two  are  categorized  as  Object  Management  services  and  the  third  as 
a  User  Interface  service.  Differing  strategies  for  Object  Management  services  are  a  partial 
reason  for  the  current  lack  of  uniformity  that  now  exists.  In  particular,  divergent  opinion  as 

'  A  more  general  baseline,  summarized  in  Section  5  of  this  document,  can  be  found  in  the  Institute  for 
Defense  Analyses  Document  D-1386,  Current  Standardization  and  Cooperative  Efforts  Related  to  Indus¬ 
trial  Information  Infrastructures. 

^  aR  eference  Model  for  Computer  Assisted  Software  Engineering  Environment  Frameworks,  National  Insti¬ 
tute  of  Standards  and  Technology  working  draft,  prepared  by  the  NIST  Integrated  Software  Engineering 
Environment  (ISEE)  Working  Group,  May  29, 1991. 
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to  an  object-oriented  (OO)  approach  to  information  management  has  been  and  continues  to 
be  a  barrier  to  widespread  agreement  on  framework  standards. 

F.2.2  STANDARDS,  PRODUCTS,  AND  INITIATIVES 

There  are  many  initiatives  including  government-sponsored  projects,  industry  con¬ 
sortia,  and  proprietary  programs  working  in  various  areas  of  CASE  frameworks.  Few  of 
these  initiatives  are  in  direct  competition;  rather,  each  has  targeted  a  particular  subset  of  the 
frameworks  domain.  This  makes  comparisons  difficult,  since  few  programs  are  really  com¬ 
parable.  Further,  many  ongoing  initiatives  not  specific  to  CASE,  or  even  software  engineer¬ 
ing,  have  significant  overlap  with  others  that  are  specifically  in  the  CASE  domain.  As  an 
example:  CALS  (DoD’s  Computer-Aided  Acquisition  and  Logistics  Support)  embraces  the 
F*roduct  Data  Exchange  Specification  (PDES).  a  proposed  standard  for  computer  exchange 
of  data,  and  will  depend  on  SQL  (a  software  standard  for  database  queries)  and  the  Infor¬ 
mation  Resource  Dictionary  System  (IRDS).  a  specification  for  a  standard  data  dictionary 
system.  While  none  of  these  areas  (CALS,  PDES,  SQL,  IRDS)  is  particularly  centered  in 
the  domain  of  software  engineering  environments,  all  of  these  efforts  and  possible  stan¬ 
dards  are  concerned  with  software  engineering;  many  CASE  framework  standards  have 
relevance  to  these  other  areas  as  well. 

Nonetheless,  very  general  categories  may  be  useful,  even  if  only  to  organize  our 
thinking.  These  categories  are  rooted  in  simple  distinctions;  whether  the  initiative  is  gov¬ 
ernment-sponsored  or  industry;  whether  it  is  aiming  to  create  an  interface  standard  or  a  full 
product;  whether  it  is  developing  a  framework  entity  or  an  environmental  one;  whether  the 
effort  is  software-centric  or  not.  One  other  category,  that  cuts  across  these,  is  that  of  pro¬ 
files.  NB:  It  should  be  noted  that  the  term  “standard”  is  used  loosely  here,  and  may  apply 
to  existing,  developing,  or  proposed  standards. 

F.2.2. 1  General  Software  Tool  Interface  and  Integration  Standards 

Most  of  these  standards  are  commonly  referred  to  as  “frameworks,”  notwithstand¬ 
ing  the  fact  that  none  of  them  supplies  the  entire  set  of  services  called  out  in  the  NIST  Ref¬ 
erence  Model. 

F.2.2.1.I  ATIS  (A  Tools  Integration  Standard) 

ATIS  is  a  developing  OO  framework  standard  that  originated  in  a  commercial  prod¬ 
uct.  As  ATIS  matured,  it  was  subsumed  into  a  consortium  called  CIS  (CASE  Integration 
Services)  and  was  proposed  to  the  American  National  Standards  Institute  (ANSI)  as  a  for- 
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mal  working  group.  ANSI  first  rejected,  then  accepted  the  proposal;  CIS  is  now  ANSI/ 
X3H6.  ATIS  is  widely  regarded  as  the  most  mature  object-oriented  framework  standard, 
and  is  the  basis  for  a  commercial  framework  product  (Atherton’s  Software  Backplane),  and 
a  commercial  CASE  environment  (Digital  Equipment  Corporation’s  Cohesion). 

F.2.2.1.2  CAIS  (DOD-STD  1838)  (Common  Ada  Programming  Support  Environ¬ 
ment  (APSE)  Interface  Set) 

CAIS  is  based  on  an  entity-relation-attribute  (ERA)  node  model;  it  originated  in  the 
early  days  of  Ada,  and  was  developed  to  provide  tool  portability  and  tool  interoperability 
between  different  Ada  environments.  CAIS  was  superceded  by  CAIS-A  (MIL-STD- 
1838 A);  this  has  to  some  extent  been  extended  by  the  Portable  Common  Interface  Set 
(PCIS)  (^.v.)  The  CAIS  program  has  been  supported  by  the  Ada  Joint  Program  Office, 
which  is  now  a  major  supporter  of  the  PCIS  program. 

F,2.2.1.3  IRDS  (Information  Resource  Dictionary  System) 

IRDS  exists  in  two  somewhat  different  versions,  one  an  International  Organization 
for  Standardization  (ISO)  standard  and  one  an  ANSI  standard.  IRDS  defines  a  model  sim¬ 
ilar  to  a  relational  model  based  on  SQL,  and  is  aimed  at  data  modeling  in  information  sys¬ 
tems.  Information  is  stored  at  the  definition  and  at  the  IRD  level.  The  IRD  level  contains 
the  application  data.  Schema  information  is  available  through  tables  that  define  entities, 
attributes,  and  relationships;  an  object  in  ISO/IRDS  is  actually  the  result  of  a  join  of  two 
tables.  There  exist  plans  for  an  IRDS2,  though  it  is  not  known  what  effect  the  existence  of 
X3H6  will  have  on  the  development  of  IRDS2. 

F2.2.1A  P1175/D6  (IEEE  Reference  Model  for  Interconnections  Lvtween  Com¬ 

puting  System  Tools) 

PI  175  is  targeted  at  “computing  system  tools’’;  omitted  are  such  tools  as  graphical 
drawing  packages  and  word  processing;  included  are  computer-assisted  engineering  (CAE) 
and  both  variants  of  CASE  (i.e.,  “Software”  and  “System”).  The  standard  is  centered  in  the 
connections  area;  one  notable  element  is  the  notion  that  tools  are  interconnected  with  such 
items  as  organizations,  application  domains,  business  information  modeling.  This  standard 
was  to  have  been  submitted  to  the  IEEE  Computer  Society’s  Task  Force  on  Professional 
Tools.  Balloting  was  scheduled  to  take  place  during  the  Fall  of  1990;  submission  to  the 
IEEE  Standards  Board  was  scheduled  for  February  1991. 
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F^.2.1.5  PCTE  (Portable  Common  Tool  Environment) 


PCJTE,  like  CAIS,  is  an  ERA  system,  and  is  available  in  a  commercial  implementa¬ 
tion  from  Emeraude.  There  are  apparently  several  other  incipient  commercial  implementa¬ 
tions,  though  none  have  yet  been  widely  advertised.  PCTE  has  been  superceded  by  PCTE+ 
and  also  by  ECMA/PCTE.  Note  that  PCTE-»-  and  ECMA  PCTE  overlap  in  most  areas,  but 
neither  is  a  subset  of  the  other.  PCTE  is  also  a  major  ”  -  nt  in  the  PClS  program.  It  is 

the  framework  for  at  least  two  commercially  available  .aments  (EAST,  Enterprise  D). 
PCTE  is  expected  to  be  submitted  for  ISO  standardization  in  1992. 

R2.2.1.6  PClS  (Portable  Common  Interface  Set) 

PCIS  was  originally  planned  as  a  merger  between  CAIS  and  PCTE,  both  of  which 
are  ERA  systems,  and  between  which  there  is  significant  overlap.  PCIS  is  now  broader  in 
scope,  and  is  planning  to  embrace  00  concepts  as  well.  PCIS  has  recently  developed  a  set 
of  requirements,  and  is  currently  refining  them  as  well  as  defining  the  scope  of  the  standard. 
The  original  target  for  a  PCIS  specification  was  1994;  that  date  is  likely  to  change  as  the 
requirements  for  PCIS  are  refined. 

NB:  PCTE  and  ATIS  are  generally  regarded  as  the  foremost  of  the  developing  stan¬ 
dards,  and  are  also  regarded  as  competitors.  Numerous  efforts  are  being  made  to  find  a  rap¬ 
prochement  between  them.  The  Software  Technology  for  Adaptable,  Reliable  Systems 
(STARS)  Program  held  a  Frameworks  Convergence  Conference  in  January  1991,^  for  this 
purpose.  The  convergence  is  especially  likely  due  to  the  explicit  statement  (in  the  proposal 
accepted  by  ANSI)  that  the  eventual  outcome  of  X3H6  (standardization  of  ATIS/CIS)  must 
reconcile  itself  to  and  be  implementable  over  PCTE.  One  potential  route  for  this  conver¬ 
gence  may  be  the  PCIS  activity;  there  has  been  speculation  that  the  goals  of  PCIS  and  the 
ANSI  X3H6  working  group  will  essentially  converge. 

R2.2,2  Government-Sponsored  Projects  Developing  Specific  Software  Engineer¬ 
ing  Environments 

The  following  sections  contain  examples  of  many  government  projects  developing 
software  engineering  environments. 


^  Camey.  D.  and  Belz,  F.,  Report  on  the  Software  Technology  for  Adaptable,  Reliable  Systems  Conference 
on  Frameworks  Convergence,  IDA  Document  D-972,  Institute  for  Defense  Analyses,  Alexandria,  VA, 
1991. 
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R2.2J.]  ESF;  EUREKA  Software  Factory 

The  ESF  project  is  a  European  research  effort  funded  under  the  EUREKA  program. 
It  began  in  1986  and  is  intended  to  last  10  years.  The  effort  is  aimed  at  producing  a  config¬ 
urable  software  engineering  environment:  ESF  has  produced  a  reference  architecture  which 
standardizes  interfaces  between  environment  components.  Particular  characteristics  of  a 
“software  factory”  include  interface  uniformity,  incremental  interaction,  support  for 
diverse  life-cycle  paradigms,  extensibility,  tight  integration  of  components,  support  for  dis¬ 
tribution,  reuse  and  customization,  portability,  and  heterogeneity.  EUREKA  contains  the 
notion  of  a  process  model;  those  aspects  of  the  environment  driven  by  the  process  model 
are  provided  by  a  process  programming  language. 

¥2.122  SIGMA  (Software  Industrialized  Generator  and  Maintenance  Aids) 

SIGMA  is  a  joint  project  of  the  Japanese  government  and  some  50  commercial 
companies  in  Japan.  The  expected  cost  will  be  $200  million  over  a  five-year  development 
period.  Sigma  is  seen  as  an  all-embracing,  national  software  activity.  The  nucleus  of  Sigma 
is  the  Sigma  Center,  located  in  Harumi  near  Tokyo.  While  the  term  “repository”  is  not  used 
to  describe  the  Sigma  Center,  its  activities  intersect  with  many  of  those  envisioned  in  Amer¬ 
ican  repository  efforts.  A  major  component  of  Sigma  is  the  Sigma  Network,  a  Unix-based 
network  that  connects  all  Sigma  sites.  The  network  will  transmit  files,  messages,  and  will 
permit  target-machine  access  functions.  The  operating  system  for  Sigma  is  a  revision  of 
Unix  that  includes  functions  for  Japanese-language  processing,  graphics,  windows,  and 
database  functions.  Finally,  Sigma  will  be  populated  with  a  large  number  of  general-pur¬ 
pose  tools  (e.g.,  planners,  requirements  analysis  tools,  process-flow  editors). 

F2.2.1.3  SLCSE  (Software  Life  Cycle  Support  Environment) 

SLCSE  originally  was  a  project  sponsored  by  Rome  Air  Development  Center. 
Development  began  in  1986;  a  final  prototype  was  delivered  in  August  1989.  Further  work 
is  in  progress  at  this  time.  SLCSE  is  a  DEC- VAX/VMS-based  software  development  envi¬ 
ronment  framework  intended  to  present  common  and  consistent  user  interfaces  accessing 
a  comprehensive  set  of  tools  that  fully  support  MIL-STD-2167A,The  data  model  is  tailor- 
able  to  support  a  variety  of  life  cycle  models.  SLCSE  distinguishes  between  a  “Framework 
Database”  and  a  “Project  Database”;  only  the  latter  is  specified  as  using  an  ER  model.  The 
Project  Database  is  implemented  on  top  of  conunercial  relational  databases  supporting 
SQL;  it  uses  a  client-server  architecture  that  supports  integration  of  CASE  tools  resident  on 
any  platform  configured  as  a  DECnet  node.  The  project  continues  to  evolve;  the  original 
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operational  concept  of  SLCSE  included  material  from  the  STARS  Operational  Concept 
document  of  1985;  the  current  Reference  Model  used  to  describe  SLCSE  is  apparently 
based  on  the  model  from  the  NIST  Reference  Model.  One  particular  future  direction  is 
inclusion  of  an  object-oriented  data  model. 

¥2.22.4  STARS  (Software  Technology  for  Adaptable  Reliable  Systems) 

The  STARS  program  is  sponsoring  three  prime  contractors  (Boeing,  IBM,  Unisys) 
to  develop  environments  based  on  a  common  architecture  and  a  set  of  common  standards. 
The  program  is  also  heavily  aimed  at  bringing  about  a  paradigm  shift  toward  process-driv¬ 
en,  reuse-based  software  development.  The  current  set  of  common  standards  is  very  similar 
to  the  NIST  Applications  Portability  Profile  (^.v.).  The  STARS  environments  are  scheduled 
to  be  put  into  use  in  late  1993.  The  three  STARS  environments  are  intended  to  be  commer¬ 
cialized  by  the  “commercial  counterparts”  of  the  prime  contractors,  which  in  the  case  of 
Boeing  is  the  Digital  Equipment  Corporation. 

¥2.23  Industrial  Initiatives  and  Consortia 

There  are  a  very  large  number  of  commercial  efforts,  some  of  which  are  existing 
commercial  products,  others  of  which  will  soon  be  available.  One  class  of  these  products 
is  based  on  the  developing  ATIS  standard,  and  includes  Atherton’s  Software  Backplane  (a 
framework  product)  and  Digital  Equipment  Corporation’s  Cohesion  (a  populated  environ¬ 
ment).  Another  class  is  based  on  PCTE,  and  includes  Emeraude’s  implementation  of  PCTTE 
(a  framework  product),  and  two  environments  from  French  companies  (EAST  from  SFGL, 
and  Enterprise  II  from  Syseca).  There  are  several  othor  emerging  products,  about  which  lit¬ 
tle  information  has  yet  been  released.  Two  environments  from  IBM,  AD/Cycle  and  ADC/ 
CASE,  are  expected  to  be  based  on  PCTTE.  HP  Softbench,  from  Hewlett-Packard,  is  also 
expected  to  be  become  a  PCTE-based  product 

Another  set  of  efforts  is  less  clearly  commercial.  This  includes  industrial  consortia, 
sometimes  with  government  support.  The  scope  of  these  varies  widely,  for  example,  from 
development  of  a  single  standard  data  format  to  a  broad  set  of  agreements  on  standards  and 
protocols. 

F^.2  J.1  CDIF  (CASE  Data  Interchange  Format) 

The  CDIF  Technical  Committee  operates  under  the  authority  of  the  Electronic 
Industries  Association  (EIA),  a  voting  member  of  ANSI.  This  effort  appears  to  be  a  joint 
effort  of  several  commercial  participants,  though  CALS  and  PI  175/IEEE  representatives 


have  attended  CDIF  meetings.  The  CDIF  Charter  is  “To  develop  an  ANSI  standard  (even¬ 
tually  to  become  an  ISO  standard)  for  the  exchange  of  information  between  CASE  envi¬ 
ronments.”  At  the  Plenary  Session  of  CDIF  in  July  1990,  representatives  from  CALS  and 
PI  175  were  in  attendance.  In  particular,  there  was  a  strong  indication  that  members  from 
various  standard  bodies  would  welcome  cross-fertilization  between  and  among  efforts  such 
as  CDIF,  PDES,  CALS,  and  PI  175.  The  schedule  for  public  review  of  the  CDIF  standards 
was  to  occur  throughout  September  and  October  1 990. 

R2.2.4  Related  Efforts 

The  following  efforts  do  not  concentrate  on  CASE  but  are  closely  related  enough  to 
warrant  attention. 

F2.2.4.1  EIS  (Engineering  Information  Systems) 

EIS  was  a  government-sponsored  effort  led  by  Honeywell,  Inc.  The  original  con¬ 
cepts  and  requirements  for  EIS,  published  in  1986,  were  the  result  of  a  research  effort  by 
the  Institute  for  Defense  Analyses  (IDA).  EIS  is  a  system  embedded  in  an  engineering  envi¬ 
ronment,  wi  h  components  external  to  EIS  itself;  in  essence,  it  is  a  framework,  parameter¬ 
ized  by  an  imormation  model  and  described  in  a  standard  modeling  technique.  The  model 
(and  hence  the  EIS  instance)  is  object  based,  i.e.,  with  classes,  relations.  The  program 
addresses  heterogeneity  of  hardware  and  software  platforms,  data  formats,  tools,  site-spe¬ 
cific  policies,  and  inCerfaccs,  all  primaiily  oriented  toward  the  computer-assisted  engineer¬ 
ing  (CAE)  domain,  'i'he  approach  consists  of  consolidating  a  broad  set  of  functional 
requirentents,  standards,  and  guidelines  for  services  that  will  enable  and  accelerate  a  trend 
toward  uniform  engineering  ejivironments  and  information  exchange.  EIS  is  conceptually 
a  set  of  fundamental  services  (much  like  an  operating  system)  and  a  series  of  specifications 
forming  a  baseline  for  communicadon  and  implementation.  There  are  three  basic  parts:  the 
Engineering  Information  Model  (EIM),  the  EIS  Framework,  and  the  User  Interface  Man¬ 
agement  System  (UIMS).  The  EIM  contains  electronic  design  information;  it  may  be 
extended  with  site-specific  semantic  models  that  capture  site-particular  data.  The  EIM  is 
implemented  as  a  reference  schema  that  establishes  the  functional  interfaces  to  the  EIS 
data.  The  EIS  Framework  consists  of  an  Object  Management  System,  an  Application 
Object  Model,  and  Engineering  Services.  The  UIMS  consists  of  guidelines  and  candidate 
standards  for  interfaces  to  a  CAE  system;  it  concentrates  on  interfaces  for  interactive  appli¬ 
cations  and  adaptations. 
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F.2.2.4.2  SEMATECH 

SEMATECH  is  a  government-industry  consortium  concentrating  on  the  manufac¬ 
ture  of  semiconductor  devices.  It  has  a  CASE  environment  project  currently  in  require¬ 
ments  development. 

F.2.2.5  Groups/Portfolios/Profiles  of  Standards 

The  following  is  a  list  of  collections  of  standards  relevant  to  CASE  environments. 

•  NIST  Application  Portability  Profile 

•  XPG3  (X  Portability  Guide,  Version  3) 

•  STARS  Standard  Portfolio 

•  NGCR  (Next  Generation  Computer  Resources)  (a  Navy-led  DoD  activity). 
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LIST  OF  ACRONYMS 


2- D 

3- D 

3-D  EMU 

ABC 

AD 

ADE 

ADPS 

ADSRS 

ADW 

AEP 

AFARS 

AFB 

AIAG 

ALC 

AME 

AMT 

ANSA 

ANSI 

AP 

API 

APM 

APP 

APSE 

APT 

ARPA 

AQES 

ASIC 

ASPC 


Two  Dimensional 
Three  Dimensional 

Three-Dimensional  Electronic  Mock-Up 
Activity  Based  Costing 
Application  Development 
Advanced  Development  Environment 
Application  Development  Project  Support 
Automated  Drawing  Storage  and  Retrieval  System 
Application  Development  Workbench 
Application  Environment  Profiles 
(U.S.)  Air  Force  Acquisition  Regulations 
Air  Force  Base 

Automotive  Industry  Action  Group 
Air  Logistics  Center 

Association  for  Manufacturing  Excellence 

Advanced  Manufacturing  Technology;  Association  for  Manufacturing 
Technology 

Advanced  Network  Systems  Architecture 

American  National  Standards  Institute 

Application  Protocol 

Application  Programming  Interfaces 

Architecture  Projects  Management 

Application  Portability  Profile 

Ada  Programming  Support  Environment 

Application  Programming  Technology 

Advanced  Research  Projects  Agency 

Advanced  Quality  Engineering  System 

Application-Specific  Integrated  Circuit 

Automated  Semiconductor  Planning  and  Control  System 


Acronyms- 1 


ATA 

ATD 

ATF 

ATIS 

B&P 

BOM 

C^l 

CACS 

CAFE 

CAD 

CAE 

CAIS 

CALS 

CAM 

CAM-1 

CAMO 

CAPP 

CASE 

CAX 

CCIP 

CCR 

CCS 

CDF 

CDIF 

CDM 

CDRL 

CE 

CEO 

cn 

COM 

CGS 

a 

CIE 


Airline  Transportation  Agency 
Advanced  Technology  Demonstration 
Advanced  Tactical  Fighter 
A  Tools  Integration  Standard 
Bid  and  Proposal 
Bill  of  Materials 

Command,  Control,  Communications,  and  Intelligence 

Computer-Integrated  Manufacturing  (CIM)  Application  Consulting  Ser¬ 
vices 

Corporate  Average  Fuel  Economy 
Computer-Aided  Design 
Computer-Aided  Engineering 

Common  Ada  Programming  Support  Environment  (APSE)  Interface  Set 

Computer-Aided  Acquisition  and  Logistics  Support 

Computer-Aided  Manufacturing 

Computer-Aided  Manufacturing-International 

Computer-Aided  Miscellaneous  Operations 

Computer-Aided  Production  Planning 

Computer-Aided  Software  Engineering 

Computer  Aided  everything,  X  is  a  variable 

Computer-Aided  Design/Computer-Aided  Manufacturing  (CAD/CAM) 
Integration  Plan 

Commitment,  Concurrency  and  Recovery  Protocol 
Common  Communications  Support 
Common  Data  Facility 

Computer-Assisted  Software  Engineering  (CASE)  Data  Interchange  For¬ 
mat 

Common  Data  Model 
Contract  Data  Requirements  List 
Concurrent  Engineering 
Chief  Executive  Officer 

Computer-Aided  Design  (CAD)  Framework  Initiative 
Computer  Graphics  Metafile 
Corporate  Graphics  System 
Continuous  Improvement 
Computer-Integrated  Enterprise 


Acronyms-2 


CIM 

Computer- Integrated  Manufacturing 

CIM-OSA 

Computer- Integrated  Manufacturing  -  Open  System  Architecture 

CIO 

Computer  Integrated  Operations 

GIFT 

Component  Integrated  Product  Team 

CIS 

Center  for  Integrated  Systems,  Stanford  University;  Computer  -Assisted 
Software  Engineering  (CASE)  Integration  Services 

CISTAR 

Computer  Integrated  Systems,  Technologies,  and  Resources 

cms 

Contractor  Integrated  Technical  Information  Service 

CLOS 

Common  LISP  Object  System 

CMM 

Coordinate  Measuring  Machine 

CNC 

Computer  Numeric  Control 

CORBA 

Common  Object  Request  Broker  Architecture 

COF 

Customer  Order  Fulfillment 

COS 

Corporation  of  Open  Systems 

1 

COTS 

Commercial-off-the-Shelf 

CPI 

Common  Programming  Interface;  Continuous  Process  Improvement 

CPTR 

Common  Problem  Task  Report 

CPU 

Central  Processing  Unit 

CRUD 

Created,  Read,  Updated,  Deleted 

CSRC 

Computer-Aided  Acquisition  and  Logistics  System  (CALS)  Shared  Re¬ 
source  Center 

CUA 

Common  User  Access 

> 

CV 

Computer  Vision 

CVS 

Central  Version  System 

DAE 

Distributed  Application  Environment 

DARS 

Defense  Acquisitions  Regulations 

> 

DART 

Data  Archival  and  Retrieval 

DBMS 

Data  Base  Management  System 

DCE 

Distributed  Computing  Environment 

DDM 

Distributed  Data  Management 

> 

DDR&E 

Director,  Defense  Research  and  Engineering 

DEC 

Digital  Equipment  Corporation 

DECMACS 

Development  Engine  Change  Management  and  Control  System 

DEMA^AL 

IDemonstration/Validation 

> 

DES 

Data  Encryption  Standard 

> 

Acronyms-3 

DECMACS 

Development  Engine  Change  Management  and  Control  System 

DFA 

Design  for  Assembly 

DFM 

Design  for  Manufacture 

DME 

Distributed  Management  Environment 

DMU 

Digital  Mock  Up 

DoD 

Department  of  Defense 

DOME 

Distributed  Object  Management  Facility 

DPA 

Digital  Pre-Assembly 

DPU 

Defects  Per  Unit 

DRC 

Database  Relational  Common 

DRM 

DB2  unique  extension  of  DRC  (M  denotes  MVS) 

DSD 

Design  Support  Database 

DSEG 

Defense  Systems  and  Electronics  Group 

DSOM 

Distributed  System  Object  Management 

E-R 

Entity-Relationship 

EAP 

Electronic  Assembly  Plant 

EC  AD 

Electronic  Computer-Aided  Design 

ECMA 

European  Computer  Manufacturers  Association 

ECO 

Engineering  Change  Order 

EDA 

Electronic  Design  Application 

EDI 

Electronic  Data  Interchange 

EDIF 

Electronic  Data  Interchange  Format 

EDS 

Electronics  Data  Systems 

EEl 

External  Environment  Interface 

El 

Enterprise  Integration 

EIA 

Electronic  Industries  Association 

EIM 

Engineering  Information  Model 

EIP 

Enterprise  Integration  Program 

EIS 

Engineering  Information  Systems 

EISWG 

Engineering  Information  Systems  Working  Group 

EIT 

Enterprise  Integration  Technology 

EMD 

Engineering  and  Manufacturing  Division;  Engineering  and  Manufactur¬ 
ing  Development 

ENE 

Enterprise  Networking  Event 

EPA 

Enhanced  Performance  Architecture;  Environmental  Protection  Agency 

Acronyms-4 


ERA 

Entity-Relation-Attribute 

ESF 

EUREKA  Software  Factory 

ESG 

Electronic  Systems  Group 

FAA 

Federal  Aviation  Administration 

FARS 

Federal  Acquisition  Regulations 

FCS 

Factory  Control  System 

FDDl 

Fiber  Data  Digital  Interface 

FIPS 

Federal  Information  Processing  Standard 

FTAM 

File  Transfer,  Access,  and  Management 

GE 

General  Electric 

GEAE 

General  Electric  Aircraft  Engines 

GKS 

Graphics  Kernel  System 

GM 

General  Motors 

GM-C4 

General  Motors  -  Computer-Aided  Design  (CAD),  Computer-Aided 
Manufacturing  (CAM),  Computer-Aided  Engineering  (CAE),  Computer- 
Integrated  Manufacturing  (CIM) 

GNMP 

Government  Network  Management  Profile 

GOSIP 

Government  Open  Systems  Interconnection  Profile 

HLL 

High-Level  Language 

HP 

Hewlett-Packard 

HPGL 

Hewlett-Packard  Graphics  Language 

I/O 

Input/Output 

lAE 

International  Aero  Engines 

IC 

Integrated  Circuit 

ICAM-FoF 

Integrated  Computer-Aided  Manufacturing  Factory  of  the  Future 

IDA 

Institute  for  Defense  Analyses 

IDE 

Inspection  Data  Enoy 

IDEF 

ICAM  DEFinition  Language 

IDF 

Integrated  Data  Format 

IDL 

Interface  Definition  Language 

IDMS 

Integrated  Data  Management  System 

IDS 

Integrated  Design  Support  System 

IEEE 

Institute  of  Electronics  and  Electrical  Engineers,  Inc. 

lEF 

Information  Engineering  Facility;  IBM  Engineering  Framework 

lEW 

Information  Engineering  Workbench 

Acronyms- 5 


IGES 

Initial  Graphics  Exchange  Specification 

IIS 

Integrating  Infrastructure 

IISS 

Integrated  Information  Support  System 

ILS 

Integrated  Logistics  Support 

IMPCA 

Integrated  Manufacturing,  Planning,  Control,  and  Assembly 

IMPT 

Integrated  Product  Management  Team 

IMS 

Information  Management  System 

IP 

Internet  Protocol 

IPD 

Integrated  Product  Development 

IPDS 

Integrated  Product  Development  System 

IPMT 

Integrated  Product  Management  Team 

IPO 

Initial  Graphics  Exchange  Specification  -  Product  Data  Exchange  Speci¬ 
fication  (IGES-PDES)  Organization 

IPPD 

Interacted  Product/Process  Development 

IPT 

Integrated  Product  Team 

IR&D 

Internal  Research  and  Development 

IRD 

Information  Resrouce  Dictionary 

IRDS 

Information  Resource  Dictionary  System 

IRR 

Internal  Rate  of  Return 

IS 

Information  Systems 

ISA 

Instruction  Set  Architecture;  Information  Systems  Architecture  (Hughes) 

ISO 

Industrial  Sector  Division  (IBM) 

ISEE 

Integrated  Software  Engineering  Environment 

ISO 

International  Organization  for  Standardization 

ISST 

Information  Systems  Study  Team 

ITC 

Inter-Tool  Conrimunication 

IWSDB 

Integrated  Weapon  Systems  Data  Base 

JAEC 

Japan  Aero  Engine  Company 

JIT 

Just  in  lime 

JV 

Joint  Venture 

JSD 

Jackson  System  Design 

KBS 

Knowledge-Based  System 

LAPI 

Layered  Application  Program  Interface 

LASC 

Lockheed  Aeronautical  Systems  Company 

LAWS 

Lockheed  Advanced  Wiring  System 
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LCM 

LDRO 

MAP 

MBR 

MCAD 

MCAE 

MCC 

MCO 

MCS 

MCSG 

MENTRANS 

MIP 

MKS 

MMAS 

MMS 

MMST 

MPD 

MPEP 

MRP 

MS&T 

MS-DOS 

MSG 

NTMA 

MTU 

NARS 

NAS 

NASA 

NC 

NCAD 

NCAT 

NCS 

NCMS 

NCSL 

NDDL 

NDML 


Least  Common  Manager 

Long  Data  Reference  Option 

Manufacturing  Automation  Protocol 

Model  Based  Reasoning 

Mechanical  Computer-Aided  Design 

Mechanical  Computer-Aided  Engineering 

Microelectronics  and  Computer  Technologies  Corporation 

Manufacturing  Change  Order 

Material  Control  System 

Motorola  Cellular  Subscriber  Group 

MENTOR  Computer-Aided  Design  (CAD)  Translator 

Methods  Improvement  Program 

Manufacturing  Knowledge  System 

Manufacturing,  Material,  and  Acquisition  System 

Manufacturing  Message  Specification 

Microelectronics  Science  and  Technology 

Motorola  Paging  Division 

Mass  Properties  Estimation  Procedures 

Manufacturing  Resource  Planning 

Manufacturing  Science  and  Technology 

Microsoft  Disk  Operating  System 

Missile  Systems  Group  (Hughes) 

National  Tooling  and  Machine  Association 

Motoren  -  und  Turbinen-Union 

(U.S.)  Navy  Acquisition  Regulations 

Network  Application  Support 

National  Aeronautics  and  Setbacks  Administration 

Numerical  Control 

Northrop  Computer-Aided  Design 

National  Center  for  Advanced  Technologies 

Network  Computing  System 

National  Center  for  Manufacturing  Sciences 

National  Computer  Systems  Laboratory 

Neutral  Data  Definition  Language 

Neutral  Data  Manipulation  Language 
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NEMA 

NFS 

NGC 

NGCR 

NIH 

Nil 

NISC 

NIST 

NSF 

NTIS 

NTM 

NTMA 

OASD(P&L) 

ODA 

ODETTE 

ODIF 

ODL 

ODP 

OEM 

OIF 

OLE 

OMG 

OO 

OO-CORE 

OO-SQL 

OODB 

OSA 

OSAT 

OSD 

OSE 

OSF 

OSHA 

OSI 

P&L 

P&W 


( 


National  Equipment  Manufacturers  Association 

Network  File  System 

Next  Generation  Controller 

Next  Generaiton  Computer  Resources 

Not  Invented  Here 

National  Information  Infrastructure 

Northrop  Information  Services  Division  (Northrop) 

National  Institute  for  Standards  and  Technology 

National  Science  Foundation 

National  Technical  Information  Services 

Network  Transaction  Manager 

National  Tooling  and  Machine  Association 

Office  of  the  Assistant  Secretary  of  Defense  (Production  and  Logistics) 
Open  Document  Architecture 

Organization  for  Data  Exchange  by  Tele  Transmission  in  Europe 

Open  Document  Interchange  Format 

Open  Document  Language 

Open  Distributed  Processing 

Original  Equipment  Manufacturer 

Operational  Integration  Framework 

Object  Linking  and  Embedding 

Object  Management  Group 

Object  Oriented 

Object-Oriented,  Change-Oriented  Reference  Environment 

Object-Oriented  SQL 

Object-Oriented  Data  Base 

Open  System  Architecture 

Office  for  the  Study  of  Automotive  Transportation 

Office  of  the  Secretary  of  Defense 

Open  System  Environment 

Open  Software  Foundation 

Occupational  Safety  and  Health  Administration 

Open  System  Interconnection 

Profit  and  Loss 

Pratt  and  Whitney 
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PC 

Personal  Computer 

PCB 

Printed  Circuit  Board 

PCIS 

Portable  Common  Interface  Set 

PCTE 

Portable  Common  Tool  Environment 

PDCM 

Product  Data  Conceptual  Model 

PDCS 

Product  Drawing  Control  System 

PDE 

Product  Data  Exchange 

PDES 

Product  Data  Exchange  Specification 

PDM 

Product  Data  Management 

PDR 

Preliminary  Design  Review 

PDS 

Product  Definition  System 

PDUSD(A) 

Principal  Deputy  Undersecretary  of  Defense  for  Acquisition 

PHIGS 

Programmer’s  Hierarchical  Interactive  Graphics  System 

PM 

Program  Manager 

POMS 

Process-Oriented  Management  System 

POSDC 

Portable  Operating  System  Interface  for  Computer  Environments 

PRISM 

Partnership  for  Research  in  Information  Systems  Management  project 

PWA 

Printed  Wire  Assembly 

QA 

QualiQ^  Control 

QC. 

Quality  Control 

QFD 

Quality  Function  Deployment 

R&D 

Research  and  Development 

RAM 

Random  Access  Memory 

RAMP 

Rapid  Acquisition  of  Manufactured  Parts 

RDA 

Remote  Data  Access 

REF 

Repository  Enablement  Facility 

RFP 

Request  for  Proposal 

RISC 

Reduced  Instruction  Set  Computer 

RM 

Repository  Manager 

ROI 

Return  on  Investment 

RPC 

Remote  Procedure  Call 

S&CG 

Space  and  Communications  Group  (Hughes) 

S&T 

Science  and  Technology 

SA/SD 

Structured  Analysis/Structured  Design 

SAA 

Systems  Application  Architecture 
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SADT 

SAI 

SBIR 

see 

sees 

SeLM 

SE 

SEAS 

SGML 

SIG 

SIGMA 

SISP 

SLGSE 

SME 

SNA 

SOM 

SPG 

SPO 

SSD 

ST 

STARS 

STEP 

STOP 

SUMM 

SVR4 

TOP 

TES 

TEA 

T1 

TIE 

TIES 

TOP 

TP 

TQM 

TRP 


Structured  Analysis  and  Design  Technique 

Services  Access  Interface 

Small  Business  Innovative  Research 

Strategic  Gell  Gontroller 

Source  Gode  Gontrol  System 

Software  Gonfiguration  and  Library  Manager 

Software  Engineering 

Standard  Electronic  Assembly  System 

Standard  Generalized  Markup  Language 

Strategic  Interest  Group 

Software  Industrialized  Generator  and  Maintenace  Aids 

Strategic  Information  System  Planning 

Software  life  Gycle  Support  Environment 

Society  of  Manufacturing  Engineers 

Systems  Network  Architecture 

System  Object  Management 

Statistical  Process  Gontrol 

Subsystem  Project  Office 

Structured  Systems  Development 

Standards  and  Technologies 

Software  Technology  for  Adaptable,  Reliable  Systems 

Standard  for  the  Transfer  and  Exchange  of  Product  data 

Standards,  Technologies,  Organizations,  Programs 

Semantic  Unification  Meta-Model 

System  V  Release  4 

Transmission  Gontrol  Protocol 

Tool  Encapsulation  Specification 

Transparent  File  Access 

Texas  Instrument 

Team  Integration  Environment  (IBM) 

Tooling  and  Information  Engineering  System 
Technical  and  Office  Protocol 
Transaction  Processing 
Total  Quality  Management 
Technology  Reinvestment  Program 
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TTM  Time-to-Market 

U.S.  United  States 

UAW  United  Auto  Workers 

UG  Unigraphics 

U1  User  Interface 

UIMS  User  Interface  Management  System 

VECTORS  V2500  Engineering  Change  Tracking  and  Online  Reporting  System 

VHDL  Very  High  Speed  Integrated  Circuit  (VHSIC)  Hardware  Description  Lan¬ 

guage 

VI  Virtual  Terminal 

VLSI  Very  Large  Scale  Integrated  circuit 

UI  User  Interface 

WISE  Westinghouse  Integrated  Systems  Environment 

XVT  Extensible  Virtual  Tool  kit 


Acronyms- 1 1 


